370638 - (land-ro) land romanian locale on the MOZILLA_1_8_BRANCH

Status: VERIFIED FIXED

(Mozilla Localizations :: ro / Romanian, defect)

Description

[Axel Hecht [:Pike]]

Alexandru, could you please work on the trunk of the romanian cvs rep to catch up with the MOZILLA_1_8_BRANCH of en-US?

The MOZILLA_1_8_BRANCH is frozen for all locales, so we should try to get Romanian up to speed in as many landings as possible. Trunk (or HEAD, in cvs tag terms) is open, and you should have write access, though.

Comment 1

[Alexandru Szasz]

Is there a command or some parameters I'm supposed to use?

I'm familiar with cvs.

Is a "cvs commit" on the whole tree ok?

Comment 2

[Axel Hecht [:Pike]]

Please make sure that you're on the trunk before commiting (cvs status says so).

And you should in general use good check in comments, -m on commit, something like 
"bug 370638, land Firefox 2 localization on trunk, r=iulianu"

as he actually did review your stuff over in the other bug, you could reference that one, too.

Once we're moving onto the frozen branch, you'll need to reference the bugs that have the approved patch, and mention the approval, too. Which will likely be a "a=[e-mail]" instead of the r=, or in addition, if you have peers reviewing your patches.

Comment 3

[Alexandru Szasz]

I'm not sure what „you're on the trunk” means. Here's the output of cvs status:

cvs status: Examining installer/unix
===================================================================
File: install.it        Status: Locally Modified

   Working revision:    1.1
   Repository revision: 1.1     /l10n/ro/toolkit/installer/unix/install.it,v
   Sticky Tag:          MOZILLA_1_8_BRANCH (branch: 1.1.2)
   Sticky Date:         (none)
   Sticky Options:      (none)

Comment 4

[Axel Hecht [:Pike]]

That means that you're looking at the branch copy of your cvs repository.

I'd like you to land that on trunk, which you get by checking out without any branch flags.
You are probably best off with checking out the trunk in a new working copy and copying over your localization files, without the CVS dirs and their files, though. Then you need to make the cvs add and rm dance, still.

The MOZILLA_1_8_BRANCH is frozen, which means, any change going on that branch will require approval. Landing on the trunk first will get that tree in a good shape, and leave us more flexibility to actually fix things iteratively.

Comment 5

[Axel Hecht [:Pike]]

PS: the right cvs status for your example looks like

$ cvs status install.it 
===================================================================
File: install.it        Status: Up-to-date

   Working revision:    1.1
   Repository revision: 1.1     /l10n/l10n/ro/toolkit/installer/unix/install.it,v
   Sticky Tag:          (none)
   Sticky Date:         (none)
   Sticky Options:      (none)

on the trunk

Comment 6

[Alexandru Szasz]

Ok, I've landed the files on the trunk, this includes modified files and newly added files. I did not delete anything to stay on the safe side.

What's next?

Also, I'd like to know how am I able to test the translation of the installer? Are there nightly builds based on what I've put on the trunk?

If there's a document on this, please point me to it. I've found info on everything up to getting cvs access and putting files in, I have nothing on what's next.

Thank you for your patience, Axel.

Comment 7

[Alexandru Szasz]

Files are updated on trunk, did a check-l10n, everything seems ok except the two dictionary files:

 ./myspell/ro.aff
 ./myspell/ro.dic

Comment 8

[Axel Hecht [:Pike]]

Good stuff. I updated the log on my people page :-)

More comments that that script doesn't catch:

Please remove the xml files in browser/searchplugins, those searchplugins in list.txt that exist in en-US will just be taken from there, so you can remove those. If you have good suggestions for search engines for the romanian build, we should get those approved in a separate bug and land them before branching already. Wikipedia is one common example.

I'm not sure if we should have google.ro in the keyword.URL, I have to check. I guess we'd prefer to just use google.com plain. Or google does, and I'd have to see if anyone bothers.

I'll still need to do some further checks, too, before we branch, which shouldn't happen before 2.0.0.2 is safely out, which might not be an issue anymore tomorrow ;-). 

It seems that the encoding specified in toolkit/installer/windows/charset.mk doesn't work for the files in browser/installer (the properties ones). We'll need a working codepage there, you can test if will work by using 
iconv -f utf-8 -t CP1250 override.properties
etc, if you have that available. Currently it errors on ț in 
AcceptBtn=&Accept termenii din acordul de licențiere

If we can't find a proper codepage, you'll have to revert the installer back to English, sadly.

Comment 9

[Iulian Ursache-Dogariu]

Thanks Alexandru and Axel for the good work!

(In reply to comment #8)
> It seems that the encoding specified in toolkit/installer/windows/charset.mk
> doesn't work for the files in browser/installer (the properties ones). We'll
> need a working codepage there, you can test if will work by using 
> iconv -f utf-8 -t CP1250 override.properties
> etc, if you have that available. Currently it errors on ț in 
> AcceptBtn=&Accept termenii din acordul de licențiere

The ț character is actually not in CP1250, nor is it in any Windows codepage that I'm aware of. It should be safe to replace it with ţ, which _is_ in CP1250 but only slightly different (it has a cedilla instead of the correct comma below).

Comment 10

[Alexandru Szasz]

Good idea about wikipedia. How do I do it? I just add a wikipedia.xml there and add it to list.txt ?

I've replaced google.ro with google.com, I believe we can assume that people would personalize that on google.

I've deleted the rest of the xml files.

About the properties files in browser/installer

In them, there's a line that says 

# This file must be saved as UTF8 

Is this wrong ?
Should all of them be saved in the specified codepage in toolkit/installer/windows/charset.mk ?

Comment 11

[Axel Hecht [:Pike]]

Could you make sure to pick up the change in bug 372935 for the branch, too?

Regarding your questions, we should do the search stuff as part of bug 348113.

Regarding the encoding, the file is saved in UTF-8, but converted to the specified encoding at build time. The installer is a native windows app and doesn't understand utf-8 on all windows versions that we support on this branch, so we need a native windows codepage.

Comment 12

[Alexandru Szasz]

Attachment: patch to replace s with comma with s with sedila due to codepage problems in the installer on windows

Comment 13

[Axel Hecht [:Pike]]

You replaced the 't's, too, right? Looking at Iulian's comments, I'm not sure if the 's's are needed, but we'll see.

Comment 14

[Alexandru Szasz]

S's are needed too, conversion will fail if those are with comma, and afaik cp1250 does not cover s,t with comma. Maybe vista has a new codepage with these one, but xp does not.

Comment 15

[Axel Hecht [:Pike]]

Cool, if you'd land it I'll check again locally.

Comment 16

[Alexandru Szasz]

They're on the trunk, please check.

Comment 17

[Axel Hecht [:Pike]]

Attachment: language pack as generated from CVS trunk

Here is what the language pack currently would look like. I fizzled a bit so that it actually installs on all Firefox 2 versions, but that's about it.

It'd be good if you tested this a bit (maybe in addition with the locale switcher extension on amo to actually switch locales) to make sure everything works as expected.

Comment 18

[Alexandru Szasz]

Attachment: fixes some access key

I've tested it, found a few access key problems, I've attached a patch, will submit changes after a review.

Comment 19

[Axel Hecht [:Pike]]

Alexandru, unless you poked someone outside of bugzilla, the best way to ask for review is to go to the attachment details and set the review flag to '?', and to enter the bugzilla id of the person who's supposed to do the review in the textbox that's showing up then. That way that person actually knows that she or he is addressed and can track that.

Comment 20

[Alexandru Szasz]

Ok, everything else seems fine, we can proceed to the next step from my point of view.

Comment 21

[Axel Hecht [:Pike]]

Yep, this looks good to go onto the branch, morphing this bug over to branch landing.

Would you create a patch to merge the content on the trunk onto the MOZILLA_1_8_BRANCH? Right now is even a good time to land that.

Please request approval1.8.1.4 by setting that flag to '?' on the attached patch. I'll need to actually approve that patch for landing, as the MOZILLA_1_8_BRANCH is frozen. That's in contrast to trunk, where you wouldn't have had to add a a=[e-mail] to your check-ins. You only want to do that for changesets that I actually did approve by setting the flag of the day to '+'. Not a big problem on trunk, just for your information.

Comment 22

[Alexandru Szasz]

A command hint to do the merge patch would save me some time.

Comment 23

[Iulian Ursache-Dogariu]

cvs diff -u l10n/ro/ 

Or something along these lines.

Comment 24

[Axel Hecht [:Pike]]

in your trunk do a 

cvs -z3 diff -uN -r MOZILLA_1_8_BRANCH

Comment 25

[Alexandru Szasz]

Attachment: romanian locale update from 1.5 to 2.0

Patch attached. 
Thanks for all the help.

Comment 26

[Axel Hecht [:Pike]]

Comment on attachment 258119 [details]
romanian locale update from 1.5 to 2.0

[ro] approval1.8.1.4 for landing the current trunk onto the MOZILLA_1_8_BRANCH, preparing an upcoming release

Comment 27

[Alexandru Szasz]

If no action has occured yet, can I upload a patch that includes the fresh finished translated manual ?

Comment 28

[Axel Hecht [:Pike]]

Alexandru, you have approval to land on the MOZILLA_1_8_BRANCH, including the help changes. To clarify, "having approval" means nothing but permission to do so, the action item to actually check your fixes in is still on you.

Comment 29

[Alexandru Szasz]

Sorry, the files are now on the MOZILLA_1_8_BRANCH, please proceed.

Comment 30

[Axel Hecht [:Pike]]

WOOOT :-), we're almost there.

As you can see on http://tinderbox.mozilla.org/showbuilds.cgi?tree=Mozilla1.8-l10n-ro&maxdate=1174409383&legend=0, we got most your builds green, http://people.mozilla.com/~axel/status-1.8/ is looking good, too.

There is a remaining problem on windows, as can be seen on http://tinderbox.mozilla.org/showlog.cgi?log=Mozilla1.8-l10n-ro/1174403400.1174406280.23597.gz&fulltext=1. 

iconv -f UTF-8 -t CP1250 /cygdrive/c/builds/tinderbox/Fx-Mozilla1.8-l10n/WINNT_5.2_Clobber/mozilla/../l10n/ro/browser/updater/updater.ini > ../../dist/xpi-stage/locale-ro/updater.ini
iconv: /cygdrive/c/builds/tinderbox/Fx-Mozilla1.8-l10n/WINNT_5.2_Clobber/mozilla/../l10n/ro/browser/updater/updater.ini: cannot convert

That means, updater.ini needs to go through the same charset fixup as the installer properties files.

One question I had still would be the name "Bookmarks" in the bookmarks.html file, did you forget that in the localization or did you decide in general to not use a romanian name for that?

Comment 31

[Alexandru Szasz]

Thanks again for all the help.

I've replaced the character that could not be converted in updater.ini

Yes, there was a slip in the bookmarks.html file, I've added translations for bookmarks.

Everything is up on the branch.

Comment 32

[Axel Hecht [:Pike]]

Alexandru, the check-ins look good, and tinderboxens are green and produce builds now. You missed the nightlies by a cycle or so, I'll update with a link to ftp on the next round.

A note on the process, approvals are only granted for particular change sets, that is, you didn't get approval for your check-ins to updater.ini and bookmarks.html. What you should have done is do your changes locally, create a patch and attach it here, and request approval. The flag for that is approval1.8.1.4 still, it changes with each minor update. Once I had approved that patch, you could have checked it in. And, you should revisit your check-in comment, you still make it "land Firefox 2 localization on trunk", which you're not doing. You should use a comment that actually describes the change set that you're checking in at that particular check-in.

Comment 33

[Alexandru Szasz]

Attachment: update default character set + some installer text fixes

So, I've tested with the group the installer, everything looks good, no errors.
I'd still like to apply a patch if possible.

Comment 34

[Alexandru Szasz]

Attachment: compatibility fix for updater and translated two strings

Here's the patch that I was supposed to ask for approval.

Regarding the last builds, I've tested the linux and windows versions 2.0.0.3 and 2.0.0.4 pre releases and found no problems, so after commiting these patches we can proceed with the next step.

Comment 35

[Axel Hecht [:Pike]]

Comment on attachment 259664 [details] [diff] [review]
compatibility fix for updater and translated two strings

[ro] after-the-fact approval for this fix. Alexandru, thanks for the patch.

Comment 36

[Axel Hecht [:Pike]]

Comment on attachment 259663 [details] [diff] [review]
update default character set + some installer text fixes

[ro] update of installer and charsets etc approved for MOZILLA_1_8_BRANCH.

Comment 37

[Alexandru Szasz]

Changes are on trunk and on MOZILLA_1_8_BRANCH branch. I suppose we need to test another build after the web pages for romanian in bug 374742 are finished.

Comment 38

[Axel Hecht [:Pike]]

You should test your fixes from this bug on the upcoming nightlies, but yes, the web content stuff needs help and testing, too.

Comment 39

[Alexandru Szasz]

Attachment: added quotes to button names

This should be the last patch, if everything goes well after testing the nightly build, we should be done here.

Comment 40

[Axel Hecht [:Pike]]

Comment on attachment 260118 [details] [diff] [review]
added quotes to button names

[ro] fix installer buttons names, nit to bookmarks.html approved.

Comment 41

[Alexandru Szasz]

Last build is the winner, we can proceed.
As I understand the web parts are also finished.

Comment 42

[Daniel Veditz [:dveditz]]

So that means this bug is "fixed" and should have the fixed1.8.1.4 keyword?

Comment 43

[Alexandru Szasz]

Green in my opinion. We can continue with Romanian shipping in bug 352125.

I don't know who has to close this bug with fixed. I suppose Axel, since he opened it.

Comment 44

[Axel Hecht [:Pike]]

Actually, we're doing it the other way around, the person that the bug is assigned to closes the bug, per branch. I gave you the necessary priviledges to actually do so, too. Just now, though.

The fixing on the trunk is indicated by resolving the bug FIXED, testing it by changing it to VERIFIED after that. For the MOZILLA_1_8_BRANCH, use the fixed1.8.1.x and verified1.8.1.x keywords, you set those in the keyword input field on the top of the bug. In this engineering cycle, 'x' is 4, as we're working towards Firefox 2.0.0.4.

Reading your comments, verified is what you want.

Comment 45

[Axel Hecht [:Pike]]

Thanks. Removing fixed1.8.1.4 keyword as verified1.8.1.4 implies that. I did wonder if I should have said that out loud the first time around ;-)