If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

request sl locale for lanikai

RESOLVED FIXED

Status

Mozilla Localizations
sl / Slovene
--
enhancement
RESOLVED FIXED
8 years ago
7 years ago

People

(Reporter: Vito Smolej, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; sl; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 GTB7.0 (.NET CLR 3.5.30729)
Build Identifier: TB 3.1.x (Lanikai)

we are well over the 80% on the sl l10n and would like to start slowly work agains the one after next release

Reproducible: Always
(In reply to comment #0)
> we are well over the 80% on the sl l10n and would like to start slowly work
> agains the one after next release

That's great to know.

As far as I can tell there's not actually anything for us to do from the Thunderbird side:

- You are already in all-locales
- Nightly Builds of 'sl' are available here: http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-1.9.2-l10n/
- You are listed on the dashboard: https://l10n-stage-sj.mozilla.org/dashboard/?tree=tb31x

So I think the only remaining question would be, do you want to transfer the current files in the mail/ directory from:

http://hg.mozilla.org/releases/l10n-mozilla-1.9.1/sl/

to

http://hg.mozilla.org/releases/l10n-mozilla-1.9.2/sl/

so that you start the Lanikai builds from where the 3.0 builds are)?

Comment 2

8 years ago
Yes, this is mostly a question of how to start the 1.9.2 effort. Migrating a snapshot, or us taking a bundle of changesets to push.

Either way, as this is not really tb buildconfig but sl code landings, I'm moving this bug over to the Slovene l10n bugs.
Component: Build Config → sl / Slovene
Product: Thunderbird → Mozilla Localizations
QA Contact: build-config → slovene.sl

Updated

8 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 3

8 years ago
PS: Vito, I upgraded your bugzilla priviledges a bit so that you can confirm and triage bugs, as always, "use your powers wisely".
(Reporter)

Comment 4

8 years ago
Thanks, Axel! Be sure that my prime concern is always not to screw up (g). 

Mark: I know this is no chat room, but now that I have your (and Axel's) attention... Why start from releases/1.9.x !? (I know, correction, I think I know,that this is the current policy or procedure, but pls keep reading). Everything, that has to do with l10n (and much much less than the contents of releases) is in http://hg.mozilla.org/l10n-central and that's where I will push (where else?!).

One could keep all the intricacies of \releases\...\locales\XYZ out of localizers' hair, if l10n-central had a en-US subdirectory. Your side would know at any time a) which files to add b) which files to remove c) which files to change and (of course) where to take them all from. Means WE WOULD NOT NEED TO THINK OF IT. Correct me, if I am wrong, but the major part of the compare-locales has to do with differences in the tree structures between releases and l10n-central, which are LANGUAGE INDEPENDENT (!): adding en-US would reduce the compare-locales to a simple (or at least much simpler)  compare of two identically built trees (in our case en-US vs sl). 

Bootstrapping a new language would just mean making a new LX subdirectory. Cant be simpler than that. And would be much simpler than the current procedure. 

Localizers would not need to know anything about releases repository for instance no need to know about those ..../locales/XYZ subdirectories, strewn all over the place.It is insane that I need to adress (or in extremis pull) the complete product repository to get to what eventually will be the contents of a nice little XYZ.jar. (half a GB vs 400kB) 

Anybody (like us) using a CAT tool with a translation memory could sleep in peace without wondering what compare-locales will tell next: all the changes within the products realm would be reflected in a fresh new en-US branch. The localizer (locaholic) would get a fresh cup of coffee, pull the new en-US and check (with the >>CAT TOOL<<) what needs to be done. Free, free at last ... no more compare-locales. 

els, etc. 

So, please, add en-US to l10n-central - it's < 2MB and I think one can afford it (g).   

Thank you all for your attention.

Vito
(Reporter)

Comment 5

8 years ago
Just to inform all, that my commit worked - I am slowly starting to like that TortoiseHG icon, I just did not know until a day or two ago, I could click it and things would start to happen :]. 

The nightly build for Lanikai turned out OK. It is a rough-shod version and for now I am happy to have 3.0.5 version release-ready - re 3.1.x it does not have to be 3.1.0. 

Thank you all for bearing with me. It has paid so far for me and hopefully for us all. 

Regards

Vito
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED

Comment 6

8 years ago
You're wrong, on various accounts, sorry.

We have releases repos because we're working on different versions of Firefox and thunderbird at the same time, and different product codes come from different combinations of those repos.

Pushing to l10n-central is nice, but won't ever get your work into a release. It's used to localize the nightlies of trunk builds, for Firefox that'd be 3.7pre Minefield builds.

For thunderbird 3.1, you'll need to push to 1.9.2, l10n-central is used to localize comm-central, in what may at one point become 3.2. Note that the strings for thunderbird are in a combination of comm-central and releases/mozilla-1.9.2 right now, but after the b2 builds finally go out, it will quickly move over to releases/comm-1.9.2

I wish this was less confusing, and I wish we wouldn't have to force a full clone of several repos on you guys, but sadly, our experience with partial check-outs has been bad, and unreliable in the past. Like, the beauty of just being able to do a local langpack or repack just horribly broke, rather reliably, sadly.

Oh, and last but not least, you didn't push successfully, I don't see a sl push of yours anywhere on my radar.
(Reporter)

Comment 7

8 years ago
First of all, thanks for extensive answer. It is confusing, but actually not THAT much, and yes, it is sad (g).
However, I think I start to see a the little bigger picture.  Right now, I may feel like that proverbial Geisterfahrer
("... Achtung, ein Geisterfahrer auf B5...?! Ein!? Es sind ja hunderte!!...") but be sure I have pulled now to the curb
and am waiting for Brian to ease me into the traffic correctly. 

I am surely wrong on a number of points, but given my background in translations and localizations,
I can say that the way localizers are being handled by the current system, could be improved without
breaking too many bones. For instance: after all the hoopla, the localization ends in some XYZ.jar file.
Could we not start from that end (size=200KB) instead of having to bore down through  /releases
with typical size of > half a Gigabyte? Start with the en-US. jar content and then deliver sl.jar for instance
and some (language independent) mechanism puts it away into .\locales in the ~\releases\? 

PS; this is a subject for the l10n discussion site, but I did not want to drag the subject there. I consider it resolved and fixed - as indicated below.
You need to log in before you can comment on or make changes to this bug.