768722 - [my] Firefox initial landing on aurora

Status: RESOLVED FIXED

(Mozilla Localizations :: my / Burmese, defect)

Description

[arky [:arky]]

Request initial landing of Firefox aurora files before opening up the repository for commits from localizers.

Comment 1

[arky [:arky]]

Attachment: Latest export from Narro, tested with compare-locales

Review the code for initial landing

Comment 2

[Axel Hecht [:Pike]]

Arky, can you re-export for 'my'? There are some fixes that should have landed on the narro side that make it easier to review updates.

Comment 3

[Tin Aung Lin]

Anything I can help Mr Arky?

Comment 4

[arky [:arky]]

There are about 15 translation errors, reverting these strings for now.

Comment 5

[Tin Aung Lin]

I have seen it Arky thanks you.

Comment 6

[arky [:arky]]

Attachment: Burmese Export (31 July) Tested with Compare Locales

Comment 7

[Axel Hecht [:Pike]]

This has a broken installer, for example,

CONTEXT_OPTIONS=$BrandSh&ortName အပြင်အဆင်များ
CONTEXT_SAFE_MODE=လုံခြုံသော $Brand&ShortName 

http://a.maimult.ro/lmo/translate.php?l=my-MM&p=28&f=/browser/installer/custom.properties&t=6&s=&o=0&h=1&m=10&i=0 shows that the locale would likely want to use en-US accesskeys.

Alexandru, any suggestion on how to fix this?

Comment 8

[Axel Hecht [:Pike]]

Comment on attachment 647469 [details]
Burmese Export (31 July) Tested with Compare Locales

r- due to the broken installer.

Also, region.properties is translated, which it should not be, and intl.properties needs untranslation of intl.menuitems.insertseparatorbeforeaccesskeys, and customization of general.useragent.locale (should be 'my'), and intl.accept_languages, see the localization note there.

It'd also be good if the export wouldn't insist on adding en-US searchplugins, those must not be in the l10n trees.

There are more a11y issues, like

Yes=&Yes
No=&No
Save=&Save
Revert=&Revert
DontSave=Do&n't Save

in toolkit/chrome/global/commonDialogs.properties, the one in search.properties, two in passwordmgr.properties.

Comment 9

[Alexandru Szasz]

Attachment: Burmese Export (August 4) Tested with Compare Locales

toolkit/chrome/global/commonDialogs.properties, fixed according to:
http://a.maimult.ro/lmo/files.php?l=my-MM&p=28&pf=&s=commonDialogs.properties

passwordmgr.properties fixed according to:
http://a.maimult.ro/lmo/files.php?l=my-MM&p=28&pf=&s=passwordmgr.properties

Assuming similar cases are fixed too.

region.properties and xml search plugins marked as not to be exported (can be done in Narro). Is list.txt the same ? Should it be submitted via bugzilla ?

intl.menuitems.insertseparatorbeforeaccesskeys restored; this raises a question if it's easy to determine automatically what is a setting and what needs translation; or at least say what files will always have settings besides translations, or only settings

intl.accept_languages and general.useragent.locale set to my, this could have been done within Narro.

Noting all these down, if I can get some answers I could alter Narro for these many exceptions to make life easier for new locales.

Attaching an updated zip file.

Comment 10

[Alexandru Szasz]

Comment on attachment 648981 [details]
Burmese Export (August 4) Tested with Compare Locales

Axel, can you please have a look again at this ? Thank you.

Comment 11

[Tin Aung Lin]

(In reply to Axel Hecht [:Pike] from comment #7)
> This has a broken installer, for example,
> 
> CONTEXT_OPTIONS=$BrandSh&ortName အပြင်အဆင်များ
> CONTEXT_SAFE_MODE=လုံခြုံသော $Brand&ShortName 
> 
> http://a.maimult.ro/lmo/translate.php?l=my-MM&p=28&f=/browser/installer/
> custom.properties&t=6&s=&o=0&h=1&m=10&i=0 shows that the locale would likely
> want to use en-US accesskeys.
> 
> Alexandru, any suggestion on how to fix this?

I checked and fix the shortcuts exactly like en-US.There are most of the strings are translated by me.

Comment 12

[Alexandru Szasz]

The above was a bug, and was present only after exporting, so there are no broken translations in Narro.

Comment 13

[Axel Hecht [:Pike]]

Comment on attachment 648981 [details]
Burmese Export (August 4) Tested with Compare Locales

Hi Alexandru, thanks for your help.

I still see a few bustages:

in dom/layout/htmlparser.properties, diffed against aurora en-US:

-errUnescapedAmpersandInterpretedAsCharacterReference=The string following “&” was interpreted as a character reference. (“&” probably should have been escaped as “&”.)
-errNotSemicolonTerminated=Named character reference was not terminated by a semicolon. (Or “&” should have been escaped as “&”.)
-errNoNamedCharacterMatch=“&” did not start a character reference. (“&” probably should have been escaped as “&”.)
+
+
+errUnescapedAmpersandInterpretedAsCharacterReference=The string following “” was interpreted as a character reference. (“” probably should have been escaped as “&”.)
+errNotSemicolonTerminated=Named character reference was not terminated by a semicolon. (Or “” should have been escaped as “&”.)
+errNoNamedCharacterMatch=“” did not start a character reference. (“” probably should have been escaped as “&”.)

This is still ampersand weirdness.

-errImage=Saw a start tag “image”.
+errImage=Bad start tag “%1$S” in “head”.

No idea where that string is coming from?

Nit, I also see an extra empty line at the end.

In browser/chrome/browser/quitDialog.properties, the *Title strings are not accessible, & missing.

browser/chrome/browser-region/region.properties is probably better to have outside of narro, and I guess that list.txt might be good to be in the same bucket. How does that impact exporting updates, though?

browser/installer/*.properties still has issues with '&' missing or being interleaved with $BrandShortName. Or again?

toolkit/chrome/global/commonDialogs.properties isn't accessible. Same for toolkit/chrome/passwordmgr/passwordmgr.properties and toolkit/chrome/search/search.properties. Any tips on how to fix those?

Comment 14

[Alexandru Szasz]

Attachment: Burmese Export (August 9) Tested with Compare Locales

Fixed all but the missing access keys mentioned at the last point.

In Narro, I'm trying to use the translation memory to its maximum potential, that means stripping of access keys in this form:

key=Open &file

In this case, I'm storing Open file as text and f as access key.
If the access key is not set in Narro, and the original access key is not present in the translation, I have no easy way of auto assigning one.

So in short, the solution is to set that in Narro rather than doing automations.

I'll add warnings on exports with links to set those access keys.

Comment 15

[Axel Hecht [:Pike]]

Comment on attachment 650595 [details]
Burmese Export (August 9) Tested with Compare Locales

This is getting closer, thanks for helping out.

Now the installer isn't busted with broken variables anymore, but it's not accessible either. Alexandru, can you help us getting an installer with accesskey and without broken variables from narro?

Nit, in custom.properties, CONTEXT_SAFE_MODE and UN_REMOVE_PROFILES are completely empty now?

Comment 16

[Axel Hecht [:Pike]]

Hi, Alexandru, do you have an update here?

Comment 17

[arky [:arky]]

Alexx mentioned that these keys are not set by the translators. Fixing it

Comment 18

[Dwayne Bailey]

Attachment: l10n files for my

These are the l10n/ files exported from Pootle.

I had to mark a number of HTML and variable errors as needing review so these will be in English in this export.

user1 and user2 goals are still not complete as I would like (319 and 709 words need review), but I assume this is because of my reviews.  If the content is close to correct with only tags and variables needing fixing then this should be quick to get to 100% (but I can't evaluate that).

Comment 19

[Tin Aung Lin]

I completed user1 & config1 folder what more need to do with user1?
Let me know!

Comment 20

[Axel Hecht [:Pike]]

Comment on attachment 696315 [details]
l10n files for my

Hi Dwayne, thanks for the update.

The technical side looks mostly OK, I did have to remove teh en-US searchplugins again, and also make some technical edits to region.properties and intl.properties. The major chunk landed as http://hg.mozilla.org/releases/l10n/mozilla-aurora/my/rev/2a2c0f154a9a, the follow-ups as http://hg.mozilla.org/releases/l10n/mozilla-aurora/my/rev/1814b157261b. Can you upstream those into pootle?

Also, http://en.wikipedia.org/wiki/Burmese_language#Numerical_classifiers makes me wonder if we need a non-1 plural form for Burmese? If you know, that'd be great, otherwise we should probably file a follow-up?

I'd prefer to add my to the aurora builds after the migration on the 7th, to keep things clear. With less than a week on aurora, Burmese doesn't sound like a good candidate for 19.

Comment 21

[Axel Hecht [:Pike]]

Dwayne, can you resolve this bug when we know about the follow-ups?

Comment 22

[Tin Aung Lin]

This bugs solved ?

Comment 23

[arky [:arky]]

Dwayne, Can you land one more update. Tinaunglinn has helped us resolve most of the translation checks.

Comment 24

[Dwayne Bailey]

Reviewed the inclusion of all of Axel's changes in comment 20.  All are in just aligned intl_acceptlanguages with the diff from Axel.  So all are aligned now in Pootle and Mercurial.

Comment 25

[Dwayne Bailey]

All the Pootle changes have made it in with a number of commits since then. All Axel's changes are still correct.