246163 - l10n: Patches for handling localization of preference panes easier in AppleGlot

Status: VERIFIED FIXED

(Camino Graveyard :: General, defect)

Description

[Janus]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040517 Camino/0.8b
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040517 Camino/0.8b

l10n patches.

In respond to comment 16 in bug # 232821.  A new bug report is filed.

As the original bug stated, 5 "Localizable.strings" files inside the 5 prefpanes
of Camino are either missing a line or not exists at all.  Furthermore, the
"Localizable.strings" and "RegionNames.strings" files inside the "English.lproj"
folder of "Appearance.prefpane" are encoded in UTF-8/ASCII instead fo UTF-16
which AppleGlot understands.   I have created an archive that contents the
correct or missing files in the hierarchy of Camino.app.  Putting those files
back to CVS would save half an hour for localizing Camino in each language
everytime.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Comment 1

[Janus]

Attachment: 5 "Localizable.strings" files and a "RegionNames.strings" file

Comment 2

[Janus]

additional comments on the attachement:
It contains 5 "Localizable.strings" files inside the 5 "English.lproj" folders
of prefpanes of Camino in their respectively location inside the "Camino.app". 
A line of '"PreferencePanelLabel" = "[Label]";' added to each of them.

Additionally, the "Localizable.strings" and "RegionNames.strings" inside
"Appearance.prefPane" are encoded in UTF-8 incorrectly.  They are converted to
UTF-16 for working correctly in AppleGlot.

The files are based on "2004/06/09-0.8" built downloaded from
ftp://ftp.mozilla.org/pub/mozilla.org/camino/nightly/2004-06-09-08-0.8/Camino.dmg.gz

Comment 3

[Ludovic Hirlimann [:Usul]]

Comment on attachment 150409 [details]
5 "Localizable.strings" files and a "RegionNames.strings" file

review by [e-mail] which does not have enough privileges to change the
flag value himself.

Comment 4

[Josh Aas]

Since this seems to be critical for localization of the fast approaching 0.8
release, marking as blocker. We really need to pay attention to localization
bugs in these last few days before the freeze.

Comment 5

[Josh Aas]

Since this patch has been marked as reviewed, I'm assuming the problem exists.

Comment 6

[Marcello Testi]

(In reply to comment #2)
> Additionally, the "Localizable.strings" and "RegionNames.strings" inside
> "Appearance.prefPane" are encoded in UTF-8 incorrectly.  They are converted to
> UTF-16 for working correctly in AppleGlot.

Actually what puzzled AppleGlot + ADViewer was not UTF-8, but ISO-8859-1 (which
was the encoding of the .strings file in Appearance and Privacy. Anyway, turning
all the .strings to UTF-16 is not wrong and adds consistency (plus maybe some
more l12y for non-latin languages).
But it's also important that the PreferencePanelLabel strings were added.
(In reply to comment #5)
> I'm assuming the problem exists
Yes, it's not a blocker, but it's the really small step that keeps from fully
automating the l10n process via AppleGlot. Otherwise, you have to manually
chnnge the encodings and add strings before or after AppleGlot treatment. It's
just ten minutes, but when you only have to update, the AppleGlot thing should
only take 1-2 minutes, so there is a difference.

Comment 7

[Mike Pinkerton (not reading bugmail)]

landed on trunk & branch. i had to do it manually, can someone verify I didn't
f- this up?

Comment 8

[Janus]

I have downloaded build 2004061308 (v0.8b+) and tried to run it thru AppleGlot
with Traditional Chinese localization.

Everything works as it supposed to be.  Thanks Mike.

Comment 9

[Jungshik Shin]

> Actually what puzzled AppleGlot + ADViewer was not UTF-8, but ISO-8859-1 (whic

If UTF-8 is fine with AppleGlot+ADViewer, why don't we use it instead of UTF-16?
UTF-16 is not 'lxr-friendly'