<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 13.09.2012 17:18, Edward Caissie
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAE5CyMjWi5sKrSzEznTuwpCC03oP=oNjuN4jNu=cYGtfW1-kvQ@mail.gmail.com"
      type="cite">On Thu, Sep 13, 2012 at 10:21 AM, Lmm Muc <span
        dir="ltr">&lt;<a moz-do-not-send="true"
          href="mailto:lmmmuc@gmail.com" target="_blank">lmmmuc@gmail.com</a>&gt;</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.&nbsp;
          <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>
        </div>
      </div>
    </blockquote>
    <br>
    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 <b>in the first place</b>.
    "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?&nbsp; <br>
    <br>
    <blockquote
cite="mid:CAE5CyMjWi5sKrSzEznTuwpCC03oP=oNjuN4jNu=cYGtfW1-kvQ@mail.gmail.com"
      type="cite">
      <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"> <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>
        </div>
      </div>
    </blockquote>
    <br>
    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.<br>
    <br>
    <blockquote
cite="mid:CAE5CyMjWi5sKrSzEznTuwpCC03oP=oNjuN4jNu=cYGtfW1-kvQ@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">
        <div>
          &nbsp;<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>
        </div>
      </div>
    </blockquote>
    <br>
    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. <br>
    <br>
    <blockquote
cite="mid:CAE5CyMjWi5sKrSzEznTuwpCC03oP=oNjuN4jNu=cYGtfW1-kvQ@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">
        <div>
          <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>
          &nbsp;</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 moz-do-not-send="true"
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>
    </blockquote>
    <br>
    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. <br>
    <br>
    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. <br>
    <br>
    I suggest this: Recommended for typical back ends, not even
    recommended for huge back ends.<br>
    <br>
    <br>
    Flynn<br>
    <br>
    <br>
    <blockquote
cite="mid:CAE5CyMjWi5sKrSzEznTuwpCC03oP=oNjuN4jNu=cYGtfW1-kvQ@mail.gmail.com"
      type="cite"><br>
      Cais.<br>
      <br>
      PS: Forgive the inline reply, it truly is not one of my favorite
      methods. EAC<br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
theme-reviewers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:theme-reviewers@lists.wordpress.org">theme-reviewers@lists.wordpress.org</a>
<a class="moz-txt-link-freetext" href="http://lists.wordpress.org/mailman/listinfo/theme-reviewers">http://lists.wordpress.org/mailman/listinfo/theme-reviewers</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>