Software Update RDF files for localized builds

RESOLVED FIXED in 1.0

Status

RESOLVED FIXED
15 years ago
3 years ago

People

(Reporter: axel, Assigned: wolf)

Tracking

unspecified

Details

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

Attachments

(1 attachment, 3 obsolete attachments)

(Reporter)

Description

15 years ago
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

15 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

15 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

15 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.
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

15 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

15 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.
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

15 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.
Severity: normal → major

Comment 9

15 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

15 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.
Attachment #161275 - Attachment mime type: text/plain → text/xml

Updated

15 years ago
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?

Comment 13

15 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

15 years ago
Whiteboard: u.m.o
(Assignee)

Comment 14

15 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

15 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

15 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

15 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

15 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

15 years ago

Updated

15 years ago
Attachment #165709 - Attachment mime type: text/plain → text/xml; charset=UTF-8

Updated

15 years ago
Attachment #165709 - Attachment mime type: text/xml; charset=UTF-8 → text/xml

Comment 19

15 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

15 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

15 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

Updated

15 years ago
Attachment #165709 - Attachment is obsolete: true
Posted 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?

Comment 24

15 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

15 years ago
Comment on attachment 165824 [details]
Fixed Hungarian update RDF for Firefox 1.0

Is hu-HU ready for posting?

Comment 26

15 years ago
(In reply to comment #25)
Yes, I think so.
(Assignee)

Comment 27

15 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

15 years ago
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?
(Assignee)

Comment 30

15 years ago
Confirmation that de-DE is complete and correct and ready to post.
Then i'm doing that hereby.
(Assignee)

Comment 32

15 years ago
Comment on attachment 165884 [details]
German de-DE update file

Posted.
Attachment #165884 - Attachment is obsolete: true
(Assignee)

Updated

15 years ago
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?
(Assignee)

Comment 34

15 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

15 years ago
Target Milestone: --- → 1.0
(Assignee)

Updated

14 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
(Assignee)

Comment 35

14 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]
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.