misc i18n improvements

[nbachiyski]

Among these:

• Consolidating some strings (the ERROR prefix)
• js_escapes
• some plural things: ngettext rename to the shorter n
• text/wording fixes

Expect some more in the coming days. I wanted to try with a smaller chunk of them first.

Please review before comitting :)

[nbachiyski]

I forgot the attachment.

[nbachiyski]

Oops, the attachment went to the old ticket - anyway - let's use this one.

[nbachiyski]

more changes, more improvements ;)

[markjaquith]

The error fix looks good, so long as it doesn't reduce translators' freedom. Are there any cases where that portion would be placed AFTER the error message?

Line 254 of the patch needs to be:

wp_die( __('You are not allowed to edit posts as this user.' ));

(forgot the "to")

I don't think we should change the name of __ngettext():

• plugins may be using __ngettext()
• translators are used to setting their .pot creation software to look for __ngettext
• It matches PHP's ngettext() function

Not sure about removing wrapping parenthesis in translations.

I like the "you cannot FOO" » "you are not allowed to FOO" change. Makes it clear that it's a permissions issue, not an error.

I'm going to try to commit some portions of this.

[markjaquith]

(In [4658]) i18n fixes, logic cleanup, wording clarifications, and more from nbachiyski. fixes #3474

[markjaquith]

Go ahead and move <strong>ERROR</strong>: isolation and removal of wrapping parenthesis from i18n to their own tickets.

[ryan]

RTL translators probably want ERROR to stay as it is.

[nbachiyski]

About __ngettext: I just forgot about the plugins :) However the original funcion name is gettext and ususally the shortcut is just __. We should surely save the __ngettext, but I would advocate for the introduction of the __n - in my opinion everybody, who is aware of the gettext -> __ correspondence will understand that __n is ngettext.

About the RTL translators: aren't there many occurences in the code of this technique - separating long expressions into two, logically independent fragments and then concatenating them? If it is really a trouble may be we should look through the code and change them all? (No, do not get tricked - the last sentence was not sarcatstic - I really meant it! :) )

I will try to prepare the separate patches tonight.

Thank you for the comments.

[ryan]

If they truly are independent, they can be concatenated. ERROR is a label that should be kept in the context of what is being labelled, in my opinion. Regardless, we definitely should review our use of concatenations.

[mdawaffe]

Some typos.

Patch attached.

[mdawaffe]

typos

[ryan]

(In [4664]) Typo fixes from mdawaffe. fixes #3474

[nbachiyski]

There should be no problem with the runtime concatenation of ERROR: and the error message. First - it is clear what ERROR: stands for and all the error messages cannot be mistaken with non-error ones. Also there should be no troubles with concatenation, but we'd better ask the translator themselves.

According to ​this document IE and FF should handle the parentheses in rtl direction corectly.

I filed two patches for these issues.

[foolswisdom]

Replying to nbachiyski:

I filed two patches for these issues.

#3511: exclude parentheses from translatable strings

#3512: reuse ERROR: prefix in internationalized strings