Closed Bug 768722 Opened 8 years ago Closed 8 years ago

[my] Firefox initial landing on aurora

Categories

(Mozilla Localizations :: my / Burmese, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: arky, Unassigned)

Details

Attachments

(1 file, 4 obsolete files)

Request initial landing of Firefox aurora files before opening up the repository for commits from localizers.
Review the code for initial landing
Attachment #639677 - Flags: review?(l10n)
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.
Anything I can help Mr Arky?
There are about 15 translation errors, reverting these strings for now.
I have seen it Arky thanks you.
Attachment #647469 - Flags: review?(l10n)
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?
Attachment #639677 - Attachment is obsolete: true
Attachment #639677 - Attachment is patch: false
Attachment #639677 - Attachment mime type: text/plain → application/zip
Attachment #639677 - Flags: review?(l10n)
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.
Attachment #647469 - Flags: review?(l10n) → review-
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.
Attachment #647469 - Attachment is obsolete: true
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.
Attachment #648981 - Flags: review?(l10n)
(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.
The above was a bug, and was present only after exporting, so there are no broken translations in Narro.
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?
Attachment #648981 - Flags: review?(l10n) → review-
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.
Attachment #648981 - Attachment is obsolete: true
Attachment #650595 - Flags: review?(l10n)
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?
Attachment #650595 - Flags: review?(l10n) → review-
Depends on: 787438
No longer depends on: 787438
Hi, Alexandru, do you have an update here?
Alexx mentioned that these keys are not set by the translators. Fixing it
Attached file 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).
Attachment #650595 - Attachment is obsolete: true
Attachment #696315 - Flags: review?(l10n)
I completed user1 & config1 folder what more need to do with user1?
Let me know!
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.
Attachment #696315 - Flags: review?(l10n) → review+
Dwayne, can you resolve this bug when we know about the follow-ups?
This bugs solved ?
Dwayne, Can you land one more update. Tinaunglinn has helped us resolve most of the translation checks.
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.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
All the Pootle changes have made it in with a number of commits since then. All Axel's changes are still correct.
You need to log in before you can comment on or make changes to this bug.