590148 - (fx40-l10n-son) [son] Firefox 4.0 release tracker Songhay

Status: RESOLVED FIXED

(Mozilla Localizations :: son / Songhay, defect)

Description

[Axel Hecht [:Pike]]

This is a tracker bug for releasing Firefox 4.0 son.

This bug is not that detailed, but as we get particular work items, they should
block this bug for tracking and discoverability.

Comment 1

[Axel Hecht [:Pike]]

Can you guys create a team page on https://wiki.mozilla.org/L10n:Teams:son for us, too? You could follow the laid out in https://wiki.mozilla.org/L10n:Teams:af.

Comment 2

[Mohomodou Houssouba]

We will take care of it as soon as possible. 

(In reply to comment #1)
> Can you guys create a team page on https://wiki.mozilla.org/L10n:Teams:son for
> us, too? You could follow the laid out in
> https://wiki.mozilla.org/L10n:Teams:af.

Comment 3

[Mohomodou Houssouba]

http://pootle.locamotion.org/son/firefox/

* Firefox 4 Songhay .po files are updated: missing and fuzzy reviewed and ready for new tests.

Comment 4

[Axel Hecht [:Pike]]

(In reply to comment #3)
> http://pootle.locamotion.org/son/firefox/
> 
> * Firefox 4 Songhay .po files are updated: missing and fuzzy reviewed and ready
> for new tests.

Any proposals from your side on how to get you to be a committer to our version control directly?

I'd suggest that you start with a hg diff against http://hg.mozilla.org/l10n-central/son/. If that sounds interesting, I'd be happy to walk you through that on irc, #l10n. Probably a good idea to already have the .po files migrated to .dtd and .properties much like you did for the registration bug.

Comment 5

[Mohomodou Houssouba]

(In reply to comment #4)
> (In reply to comment #3)
> > http://pootle.locamotion.org/son/firefox/
> > 
> > * Firefox 4 Songhay .po files are updated: missing and fuzzy reviewed and ready
> > for new tests.
> 
> Any proposals from your side on how to get you to be a committer to our version
> control directly?
> 

If I understand well, I should assume the responsibility for the follow-up. If so, I am willing to do that and make sure the controls run on a regular basis.

> I'd suggest that you start with a hg diff against
> http://hg.mozilla.org/l10n-central/son/. If that sounds interesting, I'd be
> happy to walk you through that on irc, #l10n. Probably a good idea to already
> have the .po files migrated to .dtd and .properties much like you did for the
> registration bug.

That's a good idea. I need to understand the requests better in order to respond to them effectively. At the beginning, the technical comments can be very difficult to grasp or follow. 

I will find out about the migration of .po files – at the moment I seem to fall back on older folder content. But I also see important flags like this one: son - changeset - 2:1800776fd554 (http://hg.mozilla.org/l10n-central/son/). We can better discuss the editing of potential errors on irc, skype sim or other instant messaging system. Once I understand the procedure and the critical tasks, I can set priorities in terms of review and correction.

Comment 6

[Dwayne Bailey]

I can commit to son as an interim measure, I haven't enabled automatic .dtd and .properties generation yet so I probably need to do the po2moz conversion step for son as the tools are in place for that to be quite easily done on my side.

But I'd prefer to hand over the commit role to the son team. I can get a tarball to Mohomodou for him to do the next steps if needed.

Comment 7

[Mohomodou Houssouba]

Sounds good to me. Please, if all right by you, go ahead with the interim role. Once I figure out the tasks involved, I could take over for the subsequent steps.

(In reply to comment #6)
> I can commit to son as an interim measure, I haven't enabled automatic .dtd and
> .properties generation yet so I probably need to do the po2moz conversion step
> for son as the tools are in place for that to be quite easily done on my side.
> 
> But I'd prefer to hand over the commit role to the son team. I can get a
> tarball to Mohomodou for him to do the next steps if needed.

Comment 8

[Dwayne Bailey]

(In reply to comment #7)
> Sounds good to me. Please, if all right by you, go ahead with the interim role.
> Once I figure out the tasks involved, I could take over for the subsequent
> steps.

I've committed updated translations, I'll continue to do that for the time being.

Comment 9

[Axel Hecht [:Pike]]

The last landing regressed a few things.

The fixes I landed in http://hg.mozilla.org/l10n-central/son/rev/1800776fd554 were regressed in 
http://hg.mozilla.org/l10n-central/son/diff/259b41fe06ca/toolkit/chrome/global/intl.properties
The fixes in http://hg.mozilla.org/l10n-central/son/rev/d83a5d247c8c were regressed, too, leading back to XML parsing errors and others.

Please upstream those fixes, i got to reject the sign-off on http://hg.mozilla.org/l10n-central/son/pushloghtml?changeset=34c73c8ddf50.

Also, http://hg.mozilla.org/l10n-central/son/diff/259b41fe06ca/browser/chrome/browser-region/region.properties shouldn't have landed without prior reviews, I'll comment in the respective bugs about that.

Comment 10

[Dwayne Bailey]

(In reply to comment #9)
> The last landing regressed a few things.
> 
> The fixes I landed in http://hg.mozilla.org/l10n-central/son/rev/1800776fd554
> were regressed in 
> http://hg.mozilla.org/l10n-central/son/diff/259b41fe06ca/toolkit/chrome/global/intl.properties

Darn, I did push these into the PO files.

Mohomodou -> please be careful, when I make something fuzzy I need you to look at it carefully.  Also please review 'unchanged' checks carefully, sometimes there is a good reason why 'true' should not be translated.

Axel -> I did change:
toolkit/chrome/global/intl.properties
To
intl.accept_languages=son-ml, son, fr, en-us, en

I think this follows the suggested guidelines better. Please shout if I've got it wrong

These are all fixed in 0c3b877ba9de

> The fixes in http://hg.mozilla.org/l10n-central/son/rev/d83a5d247c8c were
> regressed, too, leading back to XML parsing errors and others.
> 
> Please upstream those fixes, i got to reject the sign-off on
> http://hg.mozilla.org/l10n-central/son/pushloghtml?changeset=34c73c8ddf50.
> 
> Also,
> http://hg.mozilla.org/l10n-central/son/diff/259b41fe06ca/browser/chrome/browser-region/region.properties
> shouldn't have landed without prior reviews, I'll comment in the respective
> bugs about that.

Might need to be reverted, but I'll look at that in the new bug.

Comment 11

[Axel Hecht [:Pike]]

I've taken the current sign-off now, thanks for the update.

Re intl.accept_languages, I'd still prefer to have 'son' first, there's talk to actually replace general.useragent.locale pref with the first locale in accept in a variety of places, and I'd rather have us expose just 'son' than 'son-ML'. navigator.language is the most likely candidate, fwiw. You could trick with adding weights, if you wanted, I guess.

Comment 12

[Mohomodou Houssouba]

I agree with this point. Actually the idea is still to consolidate all efforts under the "son" locale, and we're working across borders to develop current and future tools. So we back this observation, which underpins our own quest.

Comment 13

[Dwayne Bailey]

(In reply to comment #11)
> Re intl.accept_languages, I'd still prefer to have 'son' first, there's talk to
> actually replace general.useragent.locale pref with the first locale in accept
> in a variety of places, and I'd rather have us expose just 'son' than 'son-ML'.
> navigator.language is the most likely candidate, fwiw. You could trick with
> adding weights, if you wanted, I guess.

I've put son first in the PO files.  This should appear when I next migrate the PO files.

Comment 14

[Mohomodou Houssouba]

I've checked the PO files. I am reviewing the FOSS manual section on accelerators to sort out which letters to choose for certain words to avoid clashes while maintaining visibility (son/firefox/config1/browser/chrome/browser/preferences/sync.dtd.po/translate/). I will review the rest slowly and carefully from now on.

Comment 15

[Jeff Beatty [:gueroJeff]]

Songhay has been shipping for a very long time. I'm closing this bug.