[theme-reviewers] "Public facing" text should not mean the back end, only the front end

[Lmm Muc]

On 13.09.2012 17:18, Edward Caissie wrote:
> On Thu, Sep 13, 2012 at 10:21 AM, Lmm Muc <lmmmuc at gmail.com 
> <mailto:lmmmuc at gmail.com>> wrote:
>
>     On 13.09.2012 14:56, Edward Caissie wrote:
>>     To be translation ready, all "hard-coded" text strings that are
>>     outputted to the screen should be properly addressed under the
>>     i18n guidelines.
>
>     Sure, for i18n to work, affected text must be addressed. That's a
>     technicality and does not address the issue at hand.
>
>
> This is precisely the issue at hand, "... *all* hard-coded text 
> strings that are outputted to the screen ..." (with emphasis on all).

You keep referring to a technical fact, which is that terms that appear 
on the screen must be prepared before they work with i18n. I never 
questioned that. However, this does precisely * not * address the issue 
whether back end text should be considered as "public facing" and thus 
be prepared for i18n *in the first place*. "to the screen" is a general, 
technical i18n requirement and not related to WordPress or themes 
specifically. What does the technical fact that text must be prepared to 
work with i18n have to do with the specific question whether theme back 
ends should or must be made translation-ready?

>
>>     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.
>
>     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.
>
>
> 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.

All theme text will be minimal compared to the content text, translated 
or not. This doesn't change the fact that a theme user is more likely to 
be concerned about what his XXXXXX readers/visitors/possible 
customer/subscribers/whatever will see than what he sees. The text may 
be minimal in comparison but it is viewed by all visitors, all the time.

>
>
>     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.
>
>
> 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.

I have no doubt that this would be good to have, the question is whether 
it should be a requirement, and a requirement under all circumstances 
such as the ones outlined. The problem only "falls to the author and 
translators" if it becomes established as a requirement, something that 
you seem to propose without giving further thought of a both the theme 
authors and the user's side. The alternative would be to remove text and 
place it on a web site. That is hardly better for the user, neither from 
a UX viewpoint nor anything else.

>
>
>     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.
>
>
> 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).
>
>
>     Besides that the question remains whether it is even required at
>     present as per guidelines, there is no indication it is.
>
>
> 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: 
> http://codex.wordpress.org/Theme_Review#Presentation_vs_Functionality 
> ... 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.
>

That is your interpretation, one that doesn't hold up if you look at the 
context in which the other occurrences of "public facing" on the 
wordpress.org site are being used. You have not brought up any valid 
reason as to why this should become a requirement other than "best 
practice UX". This needs to be weighed against the implications I 
brought up. There will always be things that are desirable, but I see no 
automatism to make all of them requirements, in fact there is no such 
automatism.

However, apart from what "the rules" might say or not, we shouldn't be 
trying to interpret them too much but instead have a reasonable 
discussion, one that takes into account all sides instead of saying 
things like "problem only falls to the author" as if we didn't care 
about that a single bit. Besides that, it affects the user as well, and 
making this a requirement will not necessarily help the user.

I suggest this: Recommended for typical back ends, not even recommended 
for huge back ends.


Flynn


>
> Cais.
>
> PS: Forgive the inline reply, it truly is not one of my favorite 
> methods. EAC
>
>
> _______________________________________________
> theme-reviewers mailing list
> theme-reviewers at lists.wordpress.org
> http://lists.wordpress.org/mailman/listinfo/theme-reviewers

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wordpress.org/pipermail/theme-reviewers/attachments/20120913/5137464c/attachment.htm>