Make WordPress Core

Opened 17 years ago

Closed 17 years ago

Last modified 2 years ago

#3474 closed defect (bug) (fixed)

misc i18n improvements

Reported by: nbachiyski's profile nbachiyski Owned by:
Milestone: 2.1 Priority: low
Severity: normal Version: 2.1
Component: General Keywords: bg|has-patch
Focuses: Cc:


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 :)

Attachments (3)

i18n.diff (16.4 KB) - added by nbachiyski 17 years ago.
i18n-reloaded.diff (39.7 KB) - added by nbachiyski 17 years ago.
more changes, more improvements ;)
3474.diff (3.9 KB) - added by mdawaffe 17 years ago.

Download all attachments as: .zip

Change History (15)

#1 @nbachiyski
17 years ago

  • Resolution set to invalid
  • Status changed from new to closed

I forgot the attachment.

17 years ago

#2 @nbachiyski
17 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

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

17 years ago

more changes, more improvements ;)

#3 @markjaquith
17 years ago

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.

#4 @markjaquith
17 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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

#5 @markjaquith
17 years ago

  • Version set to 2.1

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

#6 @ryan
17 years ago

RTL translators probably want ERROR to stay as it is.

#7 @nbachiyski
17 years ago

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.

#8 @ryan
17 years ago

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.

#9 @mdawaffe
17 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

Some typos.

Patch attached.

17 years ago


#10 @ryan
17 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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

#11 follow-up: @nbachiyski
17 years ago

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.

#12 in reply to: ↑ 11 @foolswisdom
17 years ago

Replying to nbachiyski:

I filed two patches for these issues.

#3511: exclude parentheses from translatable strings

#3512: reuse ERROR: prefix in internationalized strings

Note: See TracTickets for help on using tickets.