359082 - aus / patcher changes to support "pretty" version text in Software Update UI

Status: RESOLVED WORKSFORME

(AUS Graveyard :: General, defect, P3)

Description

[(not reading, please use [e-mail] instead)]

aus / patcher changes to support "pretty" version text in Software Update UI

At yesterday's bon echo meeting, schrep and beard asked if it was possible to advertise something else in the major update UI besides the actual version.

For example, if we do Fx 2.0.0.1, the version attribute in the updates.xml file would be version="2.0.0.1" (see http://wiki.mozilla.org/Software_Update:updates.xml_Format)

In the client side UI, you'd see:

"You can now download and install Firefox 2.0.0.1 now!", because we use the version as well as the brand name and this string property from 
mozilla/toolkit/locales/en-US/chrome/mozapps/update/updates.properties:

introType_major_app_and_version=You can download and install %S %S now!

For a minor update, we use:  

updateName=%S %S

I tested the client, and we could indeed set version to anything we wanted, such as version="2.0 (Security Update)"

So for a minor you'd see:

An update for Firefox is available:
Firefox 2.0 (Security Update)

[note, for the nightly channel you'd also see "nightly (<build-id>)" appended]

And for a major you'd see:

New Version Available
You can download and install Firefox 2.0 (Security Update) now!

(I'll attach some screen shots.)

Having arbitrary versions does not break the version checks in nsUpdateService.js.in (which uses nsVersionComparator.cpp) because we are still only pushing one update per updates.xml.

The other place where an arbitrary version would affect us is in the never pref, as in "app.update.never.2.0 (Security Update)".  The "never" code still works, but this is something to keep in mind, if we advertise multiple, major security updates to Fx 1.5.0.8+ users, we will want to do something like:

version="2.0 (Security Update 1)"
version="2.0 (Security Update 2)"

...so that doing "never" to the first update will not affect the second.

potential server side requirements coming next..

Comment 1

[(not reading, please use [e-mail] instead)]

Attachment: major update screen shot with "pretty" version

Comment 2

[(not reading, please use [e-mail] instead)]

Attachment: minor update screen shot with "pretty" version

Comment 3

[(not reading, please use [e-mail] instead)]

also at yesterday's meeting, beard and/or schrep asked about the format of these strings, and whether localizers could re-order the brand and the version.

These properties are localized in updates.properties (http://lxr.mozilla.org/l10n-mozilla1.8.0/find?string=updates.properties)

introType_major_app_and_version=You can download and install %S %S now!
updateName=%S %S

For these strings we are _not_ currently (see bug #357145) using the "%1$S %2$S" and "%1$S (%2$S)" format, so it is not possible to reorder the brand and the version string.

Comment 4

[(not reading, please use [e-mail] instead)]

now on to the potential aus / patcher changes we might need.

The client will request the updates snippet and include the locale, using the PREF_GENERAL_USERAGENT_LOCALE pref (which may in turn be localized, see http://lxr.mozilla.org/mozilla1.8.0/source/toolkit/mozapps/update/src/nsUpdateService.js.in#446

For example, https://aus2.mozilla.org/update/2/Firefox/2.0/2006102703/Darwin_Universal-gcc3/en-US/nightly/Darwin%208.8.1/update.xml

For the "pretty" version thing to work, AUS would have to have to serve unique snippets for each locale (which I believe it already does), but patcher would have to generate valid UTF-8 snippets for each locale, so it would need localized versions of the pretty text.

The client (in 1.5.0.8+) assumes the snippet is UTF-8 (see http://lxr.mozilla.org/mozilla1.8.0/source/toolkit/mozapps/update/src/nsUpdateService.js.in#1525)

I've generated a sample snippet with some UTF-8 japanese (that I got from http://www.mozilla.or.jp/news.rdf) and I'll attach it and a screen shot.

Comment 5

[(not reading, please use [e-mail] instead)]

Attachment: updates snippet with japanese "pretty" version string

Comment 6

[(not reading, please use [e-mail] instead)]

Attachment: screen shot

Comment 7

[(not reading, please use [e-mail] instead)]

There is one problem on the client side.

Since we use the version string as part of the "never" pref name, and the pref API expect pref names to be ascii, there will be some expected results.

For example, for the jp snippet I attached, we generate a never pref name of app.update.never.LzáY‹

To address this, I'd need to encode the potential non-ascii version string (using encodeURIComponent()) in these two places:

http://lxr.mozilla.org/mozilla1.8/source/toolkit/mozapps/update/src/nsUpdateService.js.in#1392
http://lxr.mozilla.org/mozilla1.8/source/toolkit/mozapps/update/content/updates.js#233

Comment 8

[(not reading, please use [e-mail] instead)]

logged bug #359093 to track the client side change.  It would be something to consider for the trunk ASAP, and then to backport for 2.0.0.1 / 1.5.0.9.

preed/morgamic:  this bug is currently assigned to nobody, as schrep and beard have not yet determined the priority of this enhancement to AUS / patcher.

Comment 9

[J. Paul Reed [:preed]]

(In reply to comment #4)

> For the "pretty" version thing to work, AUS would have to have to serve unique
> snippets for each locale (which I believe it already does), but patcher would
> have to generate valid UTF-8 snippets for each locale, so it would need
> localized versions of the pretty text.

I was thinking about this, and putting localized content into patcher is going to be a mess.

Would it be possible to keep the localized content in the client, and then create a new entry int he snippet that is something like securityUpdateVersion=n, and then have the client display:

"You can download and install Firefox $version, $localized_string_for_security_update $securityUpdateVersion

The only problem I see with that is languages that don't use Arabic numerals.

Coordinating l10n content for patcher is going to be really difficult, and I'm willing to bet that a lot of localizers will miss localizing this string if it's not in the l10n repo. If we could keep the l10n requirements in the client for this, that'd be best, but I don't know if it's possible.

Comment 10

[(not reading, please use [e-mail] instead)]

preed, thanks for the additional information.

I used:  "You can download and install Firefox 2.0 (Security Update 1) now!" as an example.

I was assuming that beard wanted to be able to vary the string by release, in which case localization on the client side might not be possible (unless we knew the variations ahead of time.)

Comment 11

[(not reading, please use [e-mail] instead)]

note the trunk has the fix for the client side issue (bug #359093), so if if this is something we want, we could back port that fix.

Comment 12

[Michael Morgan [:morgamic]]

Was this fixed?

Comment 13

[(not reading, please use [e-mail] instead)]

> Was this fixed?

I don't think so.

Note, this just got discussed in #granparadiso, for support "Firefox 3 Beta 2" (using version="3 Beta 2")

Comment 14

[Robert Helmer [:rhelmer]]

(In reply to comment #13)
> > Was this fixed?
> 
> I don't think so.
> 
> Note, this just got discussed in #granparadiso, for support "Firefox 3 Beta 2"
> (using version="3 Beta 2")

I'll see what it would take to do this at least, ignoring localization for now.

Comment 15

[Robert Helmer [:rhelmer]]

A more verbose version like "3 Beta 2" should be relatively easy to do, but I also think that localizing this in the patcher config file is not the right place to do it, and that it's not acceptable to do it in the client because you'd need to have all possible strings beforehand. 

We could approach this more like we do website localization, as AUS is a webservice it's not a huge stretch. The difficulty is in the way we configure AUS: there are two text files that need to be touched for every possible upgrade path, and regenerating these requires special tools.

morgamic, what do you think about makign the localization side of this bug something for AUS3? Would it be relatively easy to allow localized version strings in the database, perhaps with a fallback to the en-US version?

Comment 16

[Robert Helmer [:rhelmer]]

(In reply to comment #15)
> A more verbose version like "3 Beta 2" should be relatively easy to do, but I
> also think that localizing this in the patcher config file is not the right
> place to do it, and that it's not acceptable to do it in the client because
> you'd need to have all possible strings beforehand. 

I have been testing this and it looks like we can just set the "version" in patcher.cfg to e.g. "2.0.0.11 Beta 1" and that's what goes into the "appv" for the snippet (extv is still "2.0.0.11" as desired).

Patcher currently isn't able to set things like this per-locale so it does not solve the localization problem (and I think this is something we should push off until we're further along on AUS3 and provide a better interface to localizers on that side), but we can do a prettier, unlocalized name for Firefox 3.0 Beta 3.

Comment 17

[Robert Helmer [:rhelmer]]

I'll keep pushing on the patcher side (bug 410006), but I think the localization part should be done elsewhere, either client side or server side in the next version of AUS, our current tools would be terrible at this. Returning to pool.

Comment 18

[(not reading, please use [e-mail] instead)]

> I think the localization part should be done elsewhere, either client side

One reason to avoid doing this client side is that we need to have the localized string in the client before the update.

Comment 19

[Robert Helmer [:rhelmer]]

(In reply to comment #18)
> > I think the localization part should be done elsewhere, either client side
> 
> One reason to avoid doing this client side is that we need to have the
> localized string in the client before the update.

I agree, I think storing more of this kind of thing on the server side is the way to go. The current pre-gen method of configuration we use does not scale very well to provide this, imho, which is why I don't think we should do it using our current tools (patcher).

Comment 20

[Michael Morgan [:morgamic]]

(In reply to comment #15)
> morgamic, what do you think about makign the localization side of this bug
> something for AUS3? Would it be relatively easy to allow localized version
> strings in the database, perhaps with a fallback to the en-US version?
It's possible, and a database would make this a hell of a lot easier.

How we store it would have impacts on performance -- so I would opt to not do it the same way we stored l10n strings in AMO.

Instead, we could keep the en-US string local and do an extra lookup on non-en-US strings in a lookup table (or just add columns to make it really flat).  I am meeting with Lars tomorrow about the final draft of the AUS3 schema and will see what he thinks.

Comment 21

[Robert Strong (they/them - no direct email)]

This was implemented a while ago as a new attribute in the update snippet named displayVersion.
http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/nsIUpdateService.idl#131