Closed Bug 260842 Opened 16 years ago Closed 16 years ago

Software Update RDF files for localized builds

Categories

(addons.mozilla.org Graveyard :: Public Pages, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: axel, Assigned: wolf)

References

()

Details

(Whiteboard: [l10n Teams: see Comment #35])

Attachments

(1 file, 3 obsolete files)

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 ;-).
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.
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.
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.
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?
> 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?
(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.
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.
(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.
Severity: normal → major
(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
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.
Attachment #161275 - Attachment mime type: text/plain → text/xml
Flags: blocking-aviary1.0? → blocking-aviary1.0+
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
Will it require to upload new rdf file for every localization every time any
Firefox update will get avaible?
(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.
Whiteboard: u.m.o
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 ). 
Summary: localisation app.update.url=https://update.mozilla.org/update/firefox/en-US.rdf → Software Update RDF files for localized builds
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]
(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.
> 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.
Attached file Hungarian update RDF for Firefox 1.0 (obsolete) —
Attachment #165709 - Attachment mime type: text/plain → text/xml; charset=UTF-8
Attachment #165709 - Attachment mime type: text/xml; charset=UTF-8 → text/xml
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.)
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).
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
Attachment #165709 - Attachment is obsolete: true
Attached file German de-DE update file (obsolete) —
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?
Just translate the file, even if it doesn't seem to make sense; I cut it down to
the minimum necessary arcs.
Comment on attachment 165824 [details]
Fixed Hungarian update RDF for Firefox 1.0

Is hu-HU ready for posting?
(In reply to comment #25)
Yes, I think so.
Comment on attachment 165824 [details]
Fixed Hungarian update RDF for Firefox 1.0

hu-HU landed.
Attachment #165824 - Attachment is obsolete: true
Waiting for de-DE. Firefox 1.0 has passed, so. blocking-.
Flags: blocking-aviary1.0+ → blocking-aviary1.0-
Whiteboard: [u.m.o]
What are you waiting for in particular? Do I have to do anything else, or is
somebody else in charge?
Confirmation that de-DE is complete and correct and ready to post.
Then i'm doing that hereby.
Comment on attachment 165884 [details]
German de-DE update file

Posted.
Attachment #165884 - Attachment is obsolete: true
Status: NEW → ASSIGNED
(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?
Bulk Moving Web Site bugs to new component.
(Filter: massumowebsitespam)
Component: Update → Web Site
Product: mozilla.org → Update
Version: other → unspecified
Target Milestone: --- → 1.0
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
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]
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.