Closed Bug 415589 (fx3-l10n-eo) Opened 17 years ago Closed 16 years ago

Firefox 3 eo release tracker

Categories

(Mozilla Localizations :: eo / Esperanto, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: Pike, Unassigned)

References

Details

Attachments

(1 file)

This is a tracker bug for releasing Firefox 3 eo. This bug is not that detailed, but as we get particular work items, they should block this bug for tracking, and better discoverability. This is currently blocked by branding for Fx 2, or at least deciding on that, marking dependency.
Depends on: fx20-eo
Depends on: 402032
Depends on: 426364
Depends on: 442935
No longer depends on: 442935
Any news? Following the l10n IRC chat it seemed that everything was ready. Fx2 was to be dropped, web pages and the rest of the locales bug for Fx 3 have been dealt with. According to Mic we are in the list for 3.0.2. Anything else needs to be done before the landing?
Eduardo, I have asked for some review help from Gavin and Gandalf. Pike is swamped with a bunch of stuff leading up to 3.0.2. They should offer help shortly
Guys, please don't make things more complex still. Adding a bunch of change on top of something that's not landed is just gonna mess things up. Sorry.
Axel, if I understand right you mean that first we should upload it to CVS and then get it reviewed, right? I agree, it's easier than attaching tarballs to bugs. Who does that, the initial CVS stuff? (remember that we are already building from CVS both the binary and the language pack, the file structure should be ready to commit)
Depends on: 453106
Depends on: 453107
Depends on: 453108
Depends on: 453109
So, I added a modified version to cvs. As you don't have a cvs account yet, please do an anonymous check-out, the following should work cvs -z3 -d:pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot co mozilla/client.mk cd mozilla make -f client.mk l10n-checkout MOZ_CO_PROJECTS=browser MOZ_CO_LOCALES=eo Please check that you start working from a clean copy. Things I changed in particular include the items listed on https://wiki.mozilla.org/L10n:Review_notes. I reverted bookmarks.html (link titles should get translated again), and region.properties and searchengines. The latter two have bugs filed for the pending edits, and should only get changes after corresponding patches in bugs got successfully reviewed. Please make sure to not add back utf-7 to the charset menus. There are tinderboxens spinning now on http://tinderbox.mozilla.org/showbuilds.cgi?tree=Mozilla-l10n-eo, with better compare-locales results available on http://l10n.mozilla.org/dashboard/. You can find builds for testing on http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/latest-mozilla1.9.0-l10n/ and http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.9.0-l10n/
Depends on: 428165
CVS checkout does not seem to be working properly. This is part of the full log: ? mozilla/.mozconfig.mk ? mozilla/.mozconfig.out U mozilla/.cvsignore [...] U mozilla/xulrunner/stub/xulrunner-stub.rc cvs checkout: move away `mozilla/toolkit/.cvsignore'; it is in the way C mozilla/toolkit/.cvsignore And from then on it complains that all files ar "in the way". It happens inside an empty tree.
There seems to be an issue with character sets. The Windows build fails at the line: iconv -f UTF-8 -t CP1252 > ../../dist/xpi-stage/locale-eo/updater.ini iconv: (stdin):3:6: cannot convert The problem is that Esperanto uses ISO-8859-3 and CP1252 relates ISO-8859-1. The same command, with -t ISO-8859-3 works.
Comment #6 was a problem on our side. Sorry for the noise. About comment #7, the windows build in tinderbox has disappeared! If there aren't many files with the character set conversion problem we could use the ascii transliteration for them, until the problem is solved.
The code page problems only affect the updater.ini file, and the .properties files in browser/installer, so you should transcribe those four. Bugs are filed to not need code pages anymore, but I don't know when we'll get around to fix those.
So, in order to fix the building, if you cannot force another codepage we will go for transliteration (if it's only for some files, I guess the .ini ones). Do you agree? Should I attach a patch? The CVS account is not ready yet, and even if it was I don't know if commits are allowed right now.
Attached patch Transliterated files (deleted) — Splinter Review
This is a patch with to transliterate the files: l10n/eo/browser/installer/custom.properties l10n/eo/browser/installer/mui.properties l10n/eo/browser/installer/override.properties l10n/eo/browser/updater/updater.ini
Attachment #338408 - Flags: review?(l10n)
Attachment #338408 - Flags: review?(l10n) → review+
Comment on attachment 338408 [details] [diff] [review] Transliterated files r=me, though it's not really necessary for me to review patches like this. In general, patches should go into specific bugs that correspond to the patch in question, so here a new bug for fixing windows builds would have been a good idea.
Ok, thanks. Is this enough for the patch to make its way to the repository?
No. I hope that your account should be up any day now, so you should be able to commit it yourself then.
The cvs/hg account is not ready yet ... Do you think that making Bug 453837 block the release tracker could help make it more visible? It is actually blocking us.
Esperanto is out of beta now. Closing this bug. Thanks to all for all the work!
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: