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

Edward Caissie edward.caissie at gmail.com
Thu Sep 13 15:18:37 UTC 2012

On Thu, Sep 13, 2012 at 10:21 AM, Lmm Muc <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).

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

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

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


PS: Forgive the inline reply, it truly is not one of my favorite methods.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wordpress.org/pipermail/theme-reviewers/attachments/20120913/ca18dbbc/attachment.htm>

More information about the theme-reviewers mailing list