On Thu, Sep 13, 2012 at 10:21 AM, Lmm Muc <span dir="ltr"><<a href="mailto:lmmmuc@gmail.com" target="_blank">lmmmuc@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><div>On 13.09.2012 14:56, Edward Caissie
wrote:<br>
</div>
<blockquote type="cite">To be translation ready, all "hard-coded" text strings
that are outputted to the screen should be properly addressed
under the i18n guidelines.<br>
</blockquote>
<br></div>
Sure, for i18n to work, affected text must be addressed. That's a
technicality and does not address the issue at hand. <br></blockquote><div><br>This is precisely the issue at hand, "... *all* hard-coded text strings
that are outputted to the screen ..." (with emphasis on all).<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
<blockquote type="cite">This includes both the "public-facing" (read: text
seen by the reader); and, possibly more important, the text seen
by writer so they are provided the information on each feature /
function they are using when writing and publishing their posts,
etc.<br>
</blockquote>
<br></div>
To think that any theme user would find the back end text being
translated to be "possibly more important" than the text his
visitors see is very unlikely to say the least. I am not sure why
you would say that.<br></blockquote><div><br>The majority of text the site visitors will see and read is commonly written in the language of choice of the post / page author (read: content). The content of the site is not managed or maintained by the theme translators. Although still important, the rest of the text the reader sees is generally minimal in comparison.<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I have listed a few reasons why the back end should be officially
exempted, at least under the given circumstances, such as back end
having lots of text and images and changing, and being added to,
frequently.<br></blockquote><div><br>I would expect best practice UX for the "back-end" be that it is fully translated into the preferred language of the end-user; how often these text strings are changed is not relevant to the the end-user, only that they would be easily read in their preferred language. The problem of frequently changing strings falls to the author and the theme translators.<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Having detailed, illustrated instructions in the back end adds value
for the user. Especially with customizable themes users will have to
deal with English at one point or later, be it when reading a
tutorial or asking a question in a forum. The alternative would be
to have that text on a web site somewhere. I am sure the user would
prefer to have the text in the theme back end instead. <br></blockquote><div><br>As to the idea of images that contain text, I think its a great idea to address a possible requirement that they be handled better under i18n guidelines but that is well beyond the scope of the Theme Review Team at this time. I would suggest bringing this idea to the i18n/translations group ... (I cannot seem to find a central location to discuss this further, yet).<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Besides that the question remains whether it is even required at
present as per guidelines, there is no indication it is. <br>
<br>
</blockquote></div><br>Although translation (read: i18n) is not required, if the theme author chooses to implement these methods it is required they be implemented as noted here: <a href="http://codex.wordpress.org/Theme_Review#Presentation_vs_Functionality">http://codex.wordpress.org/Theme_Review#Presentation_vs_Functionality</a> ... perhaps the guideline needs to have "all public-facing text" clarified to read "all hard-coded text strings
that are outputted to the screen" as this is the intent considering even in the "back-end" of the theme it is public-facing text ... versus the underlying code that produces the output.<br><br><br>Cais.<br>
<br>PS: Forgive the inline reply, it truly is not one of my favorite methods. EAC<br>