Closed
Bug 260842
Opened 20 years ago
Closed 20 years ago
Software Update RDF files for localized builds
Categories
(addons.mozilla.org Graveyard :: Public Pages, defect)
addons.mozilla.org Graveyard
Public Pages
Tracking
(Not tracked)
RESOLVED
FIXED
1.0
People
(Reporter: axel, Assigned: wolf)
References
()
Details
(Whiteboard: [l10n Teams: see Comment #35])
Attachments
(1 file, 3 obsolete files)
8.55 KB,
text/xml
|
Details |
There is little knowledge out there how en-US.rdf plays together with localisation, what it is supposed to do how, who is maintaining it or its localised versions or whatnot. This came up on the l10n irc conf and couldn't be answered by Asa, Benjamin or Wolf. Parental advisory needed ;-).
Comment 1•20 years ago
|
||
I can only speculate, but I guess one needs to - copy the file for each localization of Firefox - adapt <app:infoURL> and <Description app:name> tags - adapt the <app:languages> section - upload the file to u.m.o - point the pref "app.update.url" to it - ship a build (like Firefox PR) where that pref is set accordingly. Later, when another update is available (like Firefox 1.0), and all the necessary xpis are in place, update this file, and the users of your localization will see the "updates available" button left to the throbber on the menubar, which is hidden by default.
Reporter | ||
Comment 2•20 years ago
|
||
Actually, we need something real, with l10n-hard-freeze coming up. - what is that file actually supposed to do? - why is a URL with firefox in it in a toolkit properties file, http://lxr.mozilla.org/aviarybranch/source/toolkit/locales/en-US/chrome/mozapps/update/update.properties - who is maintaining this, how, based on which information.
Comment 3•20 years ago
|
||
Agreed (at first glance) with Steffen regarding the list of things to do. Two more questions though: - How to get the localized file to u.m.o? - How to keep available locales for a given version up to date (applies to en-US.rdf also)? As for why that firefox specific file is in toolkit, when thunderbird will need the same functionnality it'll move it at the right place. I wouldn't bother with it for now.
Comment 4•20 years ago
|
||
it's getting more important for localizers with 0.10.1. Localized 1.0PR does not inform users about security update.
Flags: blocking-aviary1.0?
Comment 5•20 years ago
|
||
> it's getting more important for localizers with 0.10.1. Localized 1.0PR does not
> inform users about security update.
In fact even en-US 1.0PR did not informed me (and not only me but some friends
of mine) about the security update. Can someone please confirm if the automatic
notification worked at all?
Besides I do not think we need several ab-CD.rdf for each localization. The
en-US.rdf filename is a bit confusing, I think this file is in fact locale
independent.
In theory a user can install several language packs via extension manager when
they will be available at mozilla.org. The en-US.rdf must contain all language
packs, and all ab-CD.rdf's must contain all other language packs, too. The
patches are usually locale independent. What is the point then maintaning
different files for different locales - with the same content?
Comment 6•20 years ago
|
||
(In reply to comment #5) > > it's getting more important for localizers with 0.10.1. Localized 1.0PR does not > > inform users about security update. > > In fact even en-US 1.0PR did not informed me (and not only me but some friends > of mine) about the security update. Can someone please confirm if the automatic > notification worked at all? It did work for me, when FF was installed in a dir in which I could write. I didn't test in a read-only dir (simulating system-wide installation). All this was on en-US Linux. Did you install FF system-wide? > > Besides I do not think we need several ab-CD.rdf for each localization. The > en-US.rdf filename is a bit confusing, I think this file is in fact locale > independent. There are some locale dependant strings in that file (description of new features, name of optional functionalities). So it needs to show those in the current locale of the user. > > In theory a user can install several language packs via extension manager when > they will be available at mozilla.org. The en-US.rdf must contain all language > packs, and all ab-CD.rdf's must contain all other language packs, too. The > patches are usually locale independent. What is the point then maintaning > different files for different locales - with the same content? Listing available language packs and how to offer what's available are orthogonal to each other. In the current format of en-US.rdf, there are no provision (as far as I can tell) to offer the localizable strings (shown to the user when offering him whether or not to update) mentionned before in more than one locale. That alone needs to change, or I can point you to a whole langpack and ask "Why use it? The same info is already in en-US!". If the user can see it, it should be localizable. For the langpacks, the easiest would be to auto-generate those files from a list of available langpacks for each version, so there's no need to manually keep them all uptodate when somebody releases a new locale. Or to have some kind of include mechanism, to centralize the common information in one place. Also note that putting everything in one file will make it big quickly. The current one (as of today) describes 3 versions of FF, in a single locale (with 4 langpacks for une of the versions and 1 for the two others). Let's say all 16 locales currently in cvs are added to that same file, 3 more versions down the road (1.0RC1, 1.0RC2 and 1.0Final). The file already weights 13kB, so 13kB more for the 3 more versions, plus maybe 2kB per locale per version (2kB x 16 locales x 6 versions in total) yields around 200kB, downloaded each time FF checks if there's a newer version. Seems a lot to me, especially if checked each time you launch FF.
Comment 7•20 years ago
|
||
It may not help to find a solution, but I want to note, that this bug blocks the release of at least the german Firefox version.
Comment 8•20 years ago
|
||
(In reply to comment #6) > It did work for me, when FF was installed in a dir in which I could write. I > didn't test in a read-only dir (simulating system-wide installation). All this > was on en-US Linux. Did you install FF system-wide? No, I extracted http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/0.10/firefox-1.0PR-i686-linux-gtk2+xft.tar.gz as a normal user to its home directory on a Fedora Core 2 system. > There are some locale dependant strings in that file (description of new > features, name of optional functionalities). So it needs to show those in the > current locale of the user. Fair enough, but who will translate these strings? When a security patch lands, there is no time to wait for translators, I suppose... > > Listing available language packs and how to offer what's available are > orthogonal to each other. > I agree with the rest of your comment. Thanks for your feedback.
Updated•20 years ago
|
Severity: normal → major
Comment 9•20 years ago
|
||
(In reply to comment #8) > (In reply to comment #6) > > It did work for me, when FF was installed in a dir in which I could write. I > > didn't test in a read-only dir (simulating system-wide installation). All this > > was on en-US Linux. Did you install FF system-wide? > > No, I extracted > http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/0.10/firefox-1.0PR-i686-linux-gtk2+xft.tar.gz > as a normal user to its home directory on a Fedora Core 2 system. Could not reproduce on RH8 or FC2 (it did work here) in /tmp or under ${HOME} in both cases. Also, I'm not sure this bug is about general problems with the update mechanism, more on how to make it work for localizers. I'm sure you're not the only one having problems with the en-US update :/ > > > There are some locale dependant strings in that file (description of new > > features, name of optional functionalities). So it needs to show those in the > > current locale of the user. > > Fair enough, but who will translate these strings? When a security patch lands, > there is no time to wait for translators, I suppose... Agreed, but the 0.10.1 strings for description are the same than the 0.10 ones, so it's a simple copy/paste away for all locales.
Severity: major → normal
Comment 10•20 years ago
|
||
As suggested by bsmedberg on IRC, this is the update file for fr-FR to be placed at https://update.mozilla.org/update/firefox/fr-FR.rdf. The next version of it (for the successor of 0.10.1) will need to be manually updated as well, unless a better system is in place before then.
Updated•20 years ago
|
Attachment #161275 -
Attachment mime type: text/plain → text/xml
Updated•20 years ago
|
Flags: blocking-aviary1.0? → blocking-aviary1.0+
Comment 11•20 years ago
|
||
What steffen wrote is correct. I'll let Wolf handle committing these files... ideally they'd be pulled from cvs with the rest of the site - perhaps they can live with the localization itself and get pulled in separately...
Assignee: bugs → psychoticwolf
Component: Software Update → Update
Product: Firefox → mozilla.org
Version: 1.0 Branch → other
Comment 12•20 years ago
|
||
Will it require to upload new rdf file for every localization every time any Firefox update will get avaible?
Comment 13•20 years ago
|
||
(In reply to comment #12) > Will it require to upload new rdf file for every localization every time any > Firefox update will get avaible? There will be one rdf file for each localization, see comment 1 and comment 11. Each time an update is available for a localized build, the corresponding file needs to be updated. Just like the en-US.rdf file is updated with every update to the en-US build. That's the way to inform your users about available updates. But once you've done it the first time, it's mostly a copy and paste job since neither the product nor its components change from one version to the next. The attached fr-FR file is an example of what you have to do. In addition to comment 1: The pref "app.update.url" is set in the file update.properties. http://lxr.mozilla.org/aviarybranch/source/toolkit/locales/en-US/chrome/mozapps/update/update.properties#11 Replace en-US with your locale string.
Updated•20 years ago
|
Whiteboard: u.m.o
Assignee | ||
Comment 14•20 years ago
|
||
Yeah, I'd like them to live with the update site. ( so they'd be in CVS under /mozilla/webtools/update/update/firefox/<locale>.rdf ).
Assignee | ||
Updated•20 years ago
|
Summary: localisation app.update.url=https://update.mozilla.org/update/firefox/en-US.rdf → Software Update RDF files for localized builds
Assignee | ||
Comment 15•20 years ago
|
||
OK, we're getting close to 1.0 here. I'm willing to check in the RDF files that the various localization teams produce, just attach them here or give me a URL where I can grab it, and let me know that it is ready for check-in/publication on update.mozilla.org. :-) Thanks.
Whiteboard: u.m.o → [u.m.o]
Comment 16•20 years ago
|
||
(In reply to comment #15) > OK, we're getting close to 1.0 here. I'm willing to check in the RDF files that > the various localization teams produce, just attach them here or give me a URL > where I can grab it, and let me know that it is ready for check-in/publication > on update.mozilla.org. :-) Thanks. Do you have the 1.0 en-US.rdf available from somewhere? Else you'll have to copy-paste from 1.0PR ab-CD.rdf files, or we (and the l10n users) will have to wait for the 1.0 en-US.rdf to hit u.m.o before we get a chance to localize it, which I'm not that comfortable with.
Comment 17•20 years ago
|
||
> Do you have the 1.0 en-US.rdf available from somewhere? https://update.mozilla.org/update/firefox/en-US.rdf has been updated to 1.0.
Comment 18•20 years ago
|
||
Updated•20 years ago
|
Attachment #165709 -
Attachment mime type: text/plain → text/xml; charset=UTF-8
Updated•20 years ago
|
Attachment #165709 -
Attachment mime type: text/xml; charset=UTF-8 → text/xml
Comment 19•20 years ago
|
||
You need to change the <app:languages> section for 1.0, at the bottom of the file, from en-US to hu-HU. This tells Firefox that the update is available for hu-HU builds. Right now only en-US users would be offered the update. (And those don't look at hu-HU.rdf.)
Comment 20•20 years ago
|
||
You can try these update files by uploading your file to a webserver, make sure it is served as text/xml, and follow the instructions in http://www.mozilla.org/projects/firefox/qa/softwareupdate.html (the part on Firefox 1.0RC1&2 Users).
Comment 21•20 years ago
|
||
Plesae note that I have put up correct files (with English texts). You should download these files and just change the text: https://update.mozilla.org/update/firefox/fr-FR.rdf
Comment 22•20 years ago
|
||
Updated•20 years ago
|
Attachment #165709 -
Attachment is obsolete: true
Comment 23•20 years ago
|
||
What shall I do withe the "Available Languages" sections? We don't have any language packs for 0.10 or 0.10.1. Shall I delete that sections?
Comment 24•20 years ago
|
||
Just translate the file, even if it doesn't seem to make sense; I cut it down to the minimum necessary arcs.
Assignee | ||
Comment 25•20 years ago
|
||
Comment on attachment 165824 [details]
Fixed Hungarian update RDF for Firefox 1.0
Is hu-HU ready for posting?
Comment 26•20 years ago
|
||
(In reply to comment #25) Yes, I think so.
Assignee | ||
Comment 27•20 years ago
|
||
Comment on attachment 165824 [details]
Fixed Hungarian update RDF for Firefox 1.0
hu-HU landed.
Attachment #165824 -
Attachment is obsolete: true
Assignee | ||
Comment 28•20 years ago
|
||
Waiting for de-DE. Firefox 1.0 has passed, so. blocking-.
Flags: blocking-aviary1.0+ → blocking-aviary1.0-
Whiteboard: [u.m.o]
Comment 29•20 years ago
|
||
What are you waiting for in particular? Do I have to do anything else, or is somebody else in charge?
Assignee | ||
Comment 30•20 years ago
|
||
Confirmation that de-DE is complete and correct and ready to post.
Comment 31•20 years ago
|
||
Then i'm doing that hereby.
Assignee | ||
Comment 32•20 years ago
|
||
Comment on attachment 165884 [details]
German de-DE update file
Posted.
Attachment #165884 -
Attachment is obsolete: true
Assignee | ||
Updated•20 years ago
|
Status: NEW → ASSIGNED
Comment 33•20 years ago
|
||
(In reply to comment #24) > Just translate the file, even if it doesn't seem to make sense; I cut it down to > the minimum necessary arcs. Did you do that and if not: will it cause any harm?
Assignee | ||
Comment 34•20 years ago
|
||
Bulk Moving Web Site bugs to new component. (Filter: massumowebsitespam)
Component: Update → Web Site
Product: mozilla.org → Update
Version: other → unspecified
Assignee | ||
Updated•20 years ago
|
Target Milestone: --- → 1.0
Assignee | ||
Updated•20 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 35•20 years ago
|
||
If any of the l10n teams need their Software Update RDF updated to a translated version or added to the server entirely. Please file a bug under Update/Administration with the file attached or a link to it in your Bug Description and I'll update it for you. To see what files are currently on the Mozilla.org Application Update Server, go here: https://aus.mozilla.org/update/firefox/ Thanks.
Whiteboard: [l10n Teams: see Comment #35]
Updated•8 years ago
|
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•