26050 - editor.properties "ValidateNumberX" is hard to localise

Status: VERIFIED FIXED

(Core :: Internationalization: Localization, defect, P3)

Description

[Robert Kaiser]

Doing l10n work (M13 de-AT), I saw that /chrome/editor/.../editor.properties is
hard to localise in the following lines:

ValidateNumber1=The number you entered (
ValidateNumber2=) is outside of allowed range.<br>Please enter a number between
ValidateNumber3=and

In German, the dialog should say
"Die angegebene Zahl (ZZZ) ist au\u00DFerhalb des G\u00FCltigkeitsbereichs.
Bitte geben Sie eine Zahl zwischen XXX und YYY an."

So I'd need a "ValidateNumber4" which is not present yet.

Comment 1

[rchen]

Reassigned to Fergus.

Comment 2

[Fergus Sullivan]

Need fixed by beta.

This is a very serious problem.  When strings are concatenated like this, it 
makes translation into languages where the word order is different very 
difficult.  In this case, a German-language translation is impossible.  

A better solution here would be to insert variable placeholders into the string, 
in a manner where we can move them around if the target langauge requires it.  
An example follows:

Impossible to localize:
ValidateNumber1=The number you entered (
ValidateNumber2=) is outside of allowed range.<br>Please enter a number between
ValidateNumber3=and

Localization-friendly:
ValidateNumber=The number you entered (%num) is outside of allowed 
range.<br>Please enter a number between %lownum and %highnum

We will also need similar fixes for the following concatenated lines in this 
file:
 36 SaveFilePrompt=Save changes to 
 37 BeforeClosing=\nbefore closing
 52 DuplicateAnchorNameError=already exists in this page.<br>Please enter a 
different name.

Assigning to cmanske who seems to own this file.

Comment 3

[Charles Manske]

Sorry about this, it is tricky to figure out how to do this correctly for
all languages.
The string substitution idea is good, so this would require that %num, 
%lownum, and %highnum would not be translated, correct? 
I could add a comment to note that, then we could replace those placeholders
in the string in the C++ code.
What's the urgency for this: beta1 or later?

Comment 4

[rchen]

The fix should be in beta1.

Comment 5

[Charles Manske]

Ok, string substitution works well for all requests.
Should be checked in today.

Comment 6

[Charles Manske]

Checked in 2/9

Comment 7

[Teruko Kobayashi]

Changed QA contact to [e-mail].
Allan, please ask Ray or Fergus how to verify this.

Comment 8

[Fergus Sullivan]

Just had a look at the diffs to editor.properties v.1.14 and they look great.  
Where we once had concatenation we now how complete strings.  My only 
uncertainty is whether we can change the order of the place-holders if 
necessary--we'll have to verify that.

Meanwhile, amasri is taking a look at the appropriate UI at runtime.

Comment 9

[Charles Manske]

Absolutely - you can move the placeholders anywhere within the entire string, 
they are simply replaced with the values indicated by their names.

Comment 10

[Allan Masri]

verified with seamonkey 2000021008 build

Comment 11

[Pulsebot]

Pushed by ffxbld-merge:
https://hg.mozilla.org/releases/mozilla-beta/rev/d80898e08ffc
[fenix] Fixes https://github.com/mozilla-mobile/fenix/issues/26050: show jump back in when only synced tab available