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)
11 years ago
Depends on: 185436
Created attachment 291737 [details] [diff] [review] 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).
Assignee: nobody → stuart.morgan
Status: NEW → ASSIGNED
Attachment #291737 - Flags: superreview?(mark)
Comment on attachment 291737 [details] [diff] [review] scrub unused languages Incomplete. ("The dog ate my homework^Wpatch").
Attachment #291737 - Flags: superreview?(mark) → superreview-
Created attachment 291747 [details] [diff] [review] correct patch Same great taste, now with less FUBAR.
Comment on attachment 291747 [details] [diff] [review] correct patch A+ (or SR+) for effort, works well with others!
Attachment #291747 - Flags: superreview?(mark) → superreview+
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
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.
(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.
You need to log in before you can comment on or make changes to this bug.