[wp-trac] [WordPress Trac] #56435: Alleviate translation workload

[WordPress Trac]

#56435: Alleviate translation workload
-------------------------+------------------------------
 Reporter:  anrghg       |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  I18N         |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  2nd-opinion  |     Focuses:
-------------------------+------------------------------

Comment (by anrghg):

 Replying to [comment:2 johnbillion]:
 > Regarding using two placeholders instead of opening and closing HTML
 tags:
 >
 > * What's the benefit of doing this? It appears to be no more or less
 easy for a translator to understand, it's just different. A translator
 still needs to understand the concept of an opening and closing HTML tag
 in order to produce a correct translation using the placeholders.

 I’m pleased to learn that it’s actually better. I was only taking
 WordPress’ advice literally and got stunned when seeing all this HTML
 markup amidst the translatable strings.

 The benefit as I understood it was that translators are expected to handle
 placeholders but no HTML, and that developers are thus required to find
 ways to avoid any HTML withtin Gettext strings.

 > * Ironically making this change will increase the workload for
 translators, as we'll get 150 new strings that need to be translated.

 My pitch about “corrective action” was too hasty. Apologies. And
 consistency will require WordPress to keep making HTML part of the
 strings.

 > * I wouldn't be surprised if there are some translations which adjust or
 remove the HTML to improve formatting for a given language, which would no
 longer be possible with these placeholders (without triggering a
 translation error on w.org).

 WordPress’ advice seems to be based on the concern about translators
 breaking code; turns out translators need access to HTML? Without an
 example I can’t seem to figure out why, so I’m likely to stick with the
 original idea.

 Why would translators need to remove links? HTML already handles locale-
 dependent tweaks, e.g. in Hebrew, by lack of italic, `<em>` is rendered as
 bold, not italic, because it’s emphasis, not `<i>`.

 I don’t know how it works in Poedit, but in plain text, without HTML there
 is no need to copy-paste the ID string, the translation can be typed right
 away.

 >
 > > Try to use the same words and same symbols so not multiple strings
 needs to be translated
 >
 > This is good advice and improvements to reduce the number of similar
 strings has been ongoing for years, see for example
 https://core.trac.wordpress.org/query?component=I18N&summary=~similar .

 Like all bullet points it’s WordPress’ advice. I’ve made that mistake,
 too, and am now streamlining. I’m interested in a handy version of the
 Portable Object Message Catalog of WordPress Core. If all developers had
 such a list at hand, variations would be minimal.

 >
 > It's worth noting that "Password:" and "Password" are not the same
 string and they serve different purposes. Removing the colon to reduce the
 number of translations would result in a less appropriate phrase being
 shown to users, and it's not possible to hardcode the colon outside of the
 translation as this needs to be localisable too.

 When there is a colon, yes. In `wp-includes/post-template.php:1728` it’s
 the label of a textbox below “please enter your password below:” with a
 colon; in `wp-admin/includes/meta-boxes.php:203` it’s an input field
 label, too. The remaining instance, `wp-activate.php:183` would need a
 table instead of two paragraphs below “Your account is now active!”; only
 then would the colon be avoidable.

 >
 > If you've got some more examples of specific strings that are similar to
 others, please feel free to open individual tickets for them. Thanks!

 Thank you. Streamlining existing strings at this point would require
 discarding part of the translations, and would alleviate the workload in
 all locales added for support from now on. Is there a tool comparing
 strings across IDs? I searched strings with a colon that are likely to
 occur without, too. When starting I ignored the tool
 https://stuff.mit.edu/afs/sipb/project/gtk/gtk_v2.0/doc/gettext/gettext_6.html
 and its `merge_backup` feature. So there seems to be a lack of a tool or
 feature checking Gettext strings against each other and warning when
 punctuation causes duplicates.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/56435#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform