Closed Bug 384406 Opened 17 years ago Closed 2 years ago

Merge the multi-lingual release with the main release

Categories

(Camino Graveyard :: Translations, defect)

Product:
Camino Graveyard
Component:
Translations
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE
Milestone:
Future

People

(Reporter: markus, Unassigned)

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.4) Gecko/20061201 Firefox/2.0.0.4 (Ubuntu-feisty)
Build Identifier: 

Are there any reasons not to include translations in the main release rather than in its own multi-lingual release, other than filesize? And if so, what is the difference in filesize?

They should really be merged.

Reproducible: Always
The download of 1.5 Multilingual is about 17% larger. For past releases, where
we had more languages, the number has been higher.

Numbers on downloads of 1.5 vs 1.5 ML would be useful in deciding.
I'm in favor of shipping one single package, to rule them all.

I know (swedish) people that have been using english Camino until I noticed, because they just clicked the first download link that popped up and assumed that'd be it.
I'm on the record as being in favor of this (and would like to see it for 2.0), but when we discussed this last fall, there were several issues raised in addition to size.  Doing a single build removes flexibility for both sides--caminol10n couldn't easily re-release with more languages or fixed localizations, and we couldn't release without l10n (which we have done in the past).  And a massive set of changes to the build system to pull only complete l10ns for releases.

Also, taking 1.5 as an example, the deadline for making 1.5 would have be April 30, instead of June 3; the difference in number of l10ns would have been vast (we would have picked up a few more on the May 9 RC2 respin, but still).

I started working through the issues raised in the meeting here: http://wiki.caminobrowser.org/User:Sardisson/Towards_a_single_Camino_binary (which has a link to the meeting log with the discussion).

There are a lot of obstacles to doing this :(
(In reply to comment #1)
> Numbers on downloads of 1.5 vs 1.5 ML would be useful in deciding.

Lucky for us, bouncer doesn't track between the two, but I can guess a bit using page views for the download pages on our site. It's not perfect, but it's close...

We've had approximately 88k page views for the en-US download and 43k for the multilingual download. The number of en-US download is actually growing at a faster rate than the number of multilingual downloads, however (that is, if my stats are correct, which I think they are).
(In reply to comment #3)

> There are a lot of obstacles to doing this :(

The main one being the few resources we have for each language. We actually have a "core" small group which is able to deliver and respond timely and, even counting other people showing up quite regularly, we have only one person fully in charge for most languages with few exceptions. That makes for a very weak commitment we can give for a *always* timely ML package.

OTOH, I guess that probably giving the teams a challenging task like this, might pull the best out of (some of) them and maybe the idea to make it into the "main" distribution might sound rewarding and enticing for most.

If there was a way we could assure the releases better by growing the team, I'd feel more comfortable with this. Have we talked to the "regular" Mozilla localization teams to see if any who are Mac users would be willing to help out? I know that's a bit outside the scope of this bug, but it seem related enough to mention.
About deadlines, shouldn't the localizations follow the same logic as any other bug targeted for a given release? I.e. if a bug was targeted for version x.y.z but the assignee didn't finish it in time, it won't make it into release x.y.z.

In other words, all translators should be finished in time, otherwise that entire language will have to be left out until the next release.

May sound a bit harsh, but I mean, this is a problem regardless of whether Camino is shipped as a single package or two. It's kind of another discussion but it's related so why not.

Keeping localizations in the Camino repository would makes some things significantly easier:

1. No need for a status page (http://wiki.caminobrowser.org/Releases:1.5:l10n) since checkins to the repo would give this info.

2. No need to send out email after email on the l10n-list just to ask if translators are done but have forgotten to tell Marcello. See number 1.

3. It would be very easy to track whether localizations have picked up missing/new strings, by comparing fixed bugs with new strings, to check-ins in the localizations and their accompanying check-in messages. I.e. if I check-in HowdyHo.nib with the message "Translation of string from bug xyz" everyone will know that it's done.

Sorry for spamming this bug with lots of half-relevant stuff :)
While I get your ideal, Markus, we still have to face reality. If we get so strict at deadlines, we would have a couple of unpleasant side effects: 1) a likely growth of drop offs (quite the opposite of what I've been looking for with my recent activity...); 2) releases that show significant differences in language support from one build to another: we could have a 5 lang. Camino 1.6, followed by a 13 lang. Camino 1.7 and so on... and even n.n.x releases would show differences if we apply the same rule to the release notes.
This kind of issues, however, is better discussed on our list/website where everyone can chime in.
Is there any reason this is still UNCO? Seems like we ought to just, well, decide something. Personally, I'm in favour of merging them; that's The Mac Way™.
I'm going to confirm this, since it seems like we would like to do it, but future it since it doesn't appear to be realistic for us to do at this point. If in the future we have more stable l10n resources we can look at how to make it happen.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → Future
(In reply to comment #3)
> but when we discussed this last fall, there were several issues raised in
> addition to size.  Doing a single build removes flexibility for both
> sides--caminol10n couldn't easily re-release with more languages or fixed
> localizations

This part isn't an issue any more, since the Sparkle setup basically prohibits it (it's extraordinarily painful to do, and causes interim breakage due to mirrors and checksums).

> and we couldn't release without l10n (which we have done in the
> past).

This is still an issue, at least on the theoretical level; we certainly try not to do it.

> And a massive set of changes to the build system to pull only complete
> l10ns for releases.

> I started working through the issues raised in the meeting here:
> http://wiki.caminobrowser.org/User:Sardisson/Towards_a_single_Camino_binary
> (which has a link to the meeting log with the discussion).

Since Stuart mentioned the GTMUILocalizer stuff and we had some discussions recently, I put some time into fleshing out the build and other things we'd still have to solve yet (on the quoted wiki page above).  It's probably not complete, but it's a more accurate look at where things stand and the long road ahead, whenever we start down it.

This bug lies at rest in the graveyard.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.