401017 - Figure out l10n configuration for sparkle

Status: RESOLVED FIXED

(Camino Graveyard :: General, defect)

Description

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Sparkle ships with a ton of l10ns (yay!), including languages we don't ship at all.

We want to:

1) Ship only the English one in the English-only Camino
2) Make sure the other ones are available somehow to our l10ns, so that they don't have to re-localize any that Sparkle already provides (and any that we have to do ourselves, we should see about upstreaming)

Comment 1

[Stuart Morgan]

Attachment: scrub unused languages

This adds a script phase that strips all the languages out of Sparkle that aren't in Camino itself (since they are therefore not useful).

Comment 2

[Mark Mentovai]

Comment on attachment 291737 [details] [diff] [review]
scrub unused languages

Incomplete.  ("The dog ate my homework^Wpatch").

Comment 3

[Stuart Morgan]

Attachment: correct patch

Same great taste, now with less FUBAR.

Comment 4

[Mark Mentovai]

Comment on attachment 291747 [details] [diff] [review]
correct patch

A+ (or SR+) for effort, works well with others!

Comment 5

[Stuart Morgan]

Landed on trunk and MOZILLA_1_8_BRANCH, with logging about what it does per irc discussion (and a couple of them comment thingies).

Our current thinking is that part 2 of this should be handled by have the localizers get a version that has had the other languages added back in (from cvs) rather than getting the alpha/beta/whatever directly.

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

OK, I played with this for a little while, and I can't figure out how to make AppleGlot pick up the existing Sparkle localizations from a build that has them (pre-checkin of this patch), even with a little bit of hacking into the _NewLoc/_OldLoc folders.

What's worse, the main Sparkle.strings file (at least in the fr.lproj, which is what I was playing with, is mis-encoded, so AppleGlot/ADViewer/whatever can't see it.

The "best" solution I can see at this point is to tell the l10n teams to ignore the Sparkle stuff when doing the translations (and if all the Sparkle.stings files are mis-encoded, the bulk of the strings won't be visible, anyway) and then before they send their package back to Marcello, replace the Camino/Contents/Frameworks/Sparkle.framework/Versions/A/Resources/$LANG.lproj with the $LANG.lproj from cvs.

I'd still really like to figure out a way to get all of Sparkle's strings into a team's .ad/.wg, but right now I have no idea.

Comment 7

[Marcello Testi]

(In reply to comment #6)

> The "best" solution I can see at this point is to tell the l10n teams to ignore
> the Sparkle stuff when doing the translations (and if all the Sparkle.stings
> files are mis-encoded, the bulk of the strings won't be visible, anyway) and
> then before they send their package back to Marcello, replace the
> Camino/Contents/Frameworks/Sparkle.framework/Versions/A/Resources/$LANG.lproj
> with the $LANG.lproj from cvs.

Maybe it's better to leave this one to the ML builder. This way, this can be done once for all languages and we can even try to automate it using a script.
Of course this comment is valid for the Ml build, not if someone wants to distribute a single pkg for testing purposes, but, after all, Sparkle l10n shouldn't be tested by us.