If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

editor.properties "ValidateNumberX" is hard to localise

VERIFIED FIXED in M14

Status

()

Core
Localization
P3
normal
VERIFIED FIXED
18 years ago
18 years ago

People

(Reporter: Robert Kaiser, Assigned: Charles Manske)

Tracking

Trunk
x86
Other
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [pdt+] checkin 2/9/00)

(Reporter)

Description

18 years ago
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

18 years ago
Reassigned to Fergus.
Assignee: rchen → fergus

Updated

18 years ago
Status: NEW → ASSIGNED

Comment 2

18 years ago
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.
Assignee: fergus → cmanske
Status: ASSIGNED → NEW
Keywords: beta1
(Assignee)

Comment 3

18 years ago
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?
Status: NEW → ASSIGNED

Comment 4

18 years ago
The fix should be in beta1.
(Assignee)

Updated

18 years ago
Target Milestone: M14

Updated

18 years ago
Whiteboard: [pdt+]
(Assignee)

Comment 5

18 years ago
Ok, string substitution works well for all requests.
Should be checked in today.
(Assignee)

Updated

18 years ago
Whiteboard: [pdt+] → [pdt+] checkin 2/9/00
(Assignee)

Comment 6

18 years ago
Checked in 2/9
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 7

18 years ago
Changed QA contact to amasri@netscape.com.
Allan, please ask Ray or Fergus how to verify this.
QA Contact: teruko → amasri

Comment 8

18 years ago
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.
(Assignee)

Comment 9

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

Comment 10

18 years ago
verified with seamonkey 2000021008 build
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.