Open Bug 1064604 Opened 11 years ago Updated 11 years ago

Reply header not translated

Categories

(SeaMonkey :: MailNews: Composition, defect)

Product:
SeaMonkey
Component:
MailNews: Composition
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

People

(Reporter: iacchi, Unassigned)

Details

Starting from SeaMonkey 2.29 the reply headers (not mail headers) are not translated anymore. This is not an Italian bug because all strings are translated: http://transvision.mozfr.org/?recherche=ha+scritto&repo=release&sourcelocale=en-US&locale=it&search_type=strings but when I hit reply on an email I still get "[author] wrote" instead of "[author] ha scritto". I don't know if the problem affects later versions, but it' surely present in the 2.29.
I suspect it is because the last accepted sign-off for it was 2.26.
Flags: needinfo?(ewong)
Flags: needinfo?(bugspam.Callek)
Ok, that might be the case.
(In reply to Ian Neal from comment #1) > I suspect it is because the last accepted sign-off for it was 2.26. Certainly was, I'll be doing a run through of signoff requests tomorrow (~20 hours from now) for our 2.30 Beta 1. At which point I'll review italian at the same time. (if there is an issue that prevents signoff I'll "reject" and comment here. We'd then still use 2.26 for 2.30 Beta 1 though, and our beta 2 would have the updated fixes. I'm leaving the n-i on myself for the shear "I want to find this bug again" reason.
Flags: needinfo?(ewong)
Thanks Justin
Justin, sorry if I'm following up here, but since we're near release date... I've noticed that the signoff for beta for Italian has been rejected again, with the reason "for changes to extensions/irc/chrome/chatzilla.properties -- we're not taking an update to that this cycle" Now, I don't know exactly how the repositories for Chatzilla work, but if you don't want changes to the Chatzilla translation then don't push an updated version in the English repository. I'm using Mozilla Translator to translate SeaMonkey and I only translate the strings that comes from the English repository, because AFAIK all translations should mirror and keep up-to-date with the English strings. So, my question now is: which is the version of chatzilla.properties that you want for beta so I can revert it and you can accept the signoff for the next release? And for the future: how do we handle the fact that you don't want the file version that is in the English repositories, and how should I deal with that? How can I know if I should update a Chatzilla localisation or not? I don't have a crystal sphere...
iacchi, we have about 20 minutes where I can take an updated italian for 2.30, can you come on IRC (#seamonkey) to talk? (I'm also responding here in next comment too)
Flags: needinfo?(bugspam.Callek) → needinfo?(mozilla)
So, first off, I'm VERY sorry it took so long to review/reject the signoff. I waited until I could even get windows building, and then this whole past week we were fighting windows l10n failure modes in the code. That was preventing our beta 1 from going out. As far as chatzilla, what makes accepting/rejecting l10n so hard for it (for now) is that: * If your locale has any strings not present in the chatzilla version we build, the build will fail (e.g. if you just add something new, even without deleting existing stuff). * If your locale is missing any strings present in the chatzilla version we build, the build will also fail. So you need a 1:1 mapping of "values" from english to your locale. Unlike the rest of SeaMonkey/Firefox/Thunderbird where values are "merged" from english if they are missing, and you are able to provide extra new entities if need be. This particular complication is a long standing issue/bug in SeaMonkey, and one I'd love to find a solution for, but have been unable to get time to do so :( . As far what version of chatzilla, and why, when these strings exist, that they are not used. Firstly realize chatzilla is in its own repository (hg.mozilla.org/chatzilla) so it can diverge independant of SeaMonkey, which is unfortunate but required atm Next realize that unfortunately SeaMonkey can only ship released versions of chatzilla, not "trunk" code. this is primarily due to the extension bumping from AMO works: * if we ship a version newer than whats on AMO, when the next SeaMonkey release comes out, it won't get auto-compat-bumped. * If the chatzilla version doesn't change from one SeaMonkey version to the next, the chatzilla version we ship won't be recognized by gecko as new, and thus won't even check its compat, nor re-install itself. * Chatzilla can sometimes take longer than the trunk -> release cycle to release its changes. We also respect l10n freeze around here, so even if a chatzilla release happens, we won't take that actual release in our shipped product except on trunk, and it rides the trains until it is shipped. All that said, we need to support trunk users, who wish to deal with trunk code, so we use the `default` branch of the chatzilla repo on our Nightly/Trunk code, rather than a stable release of chatzilla. Which is likely why you've seen this code ahead of time. client.py is the preferred way to checkout code for seamonkey, and it checks out the proper revision/branch of chatzilla for whatever branch you're on. Note that client.py checks out `default` when run on trunk, and the specific branch when run on aurora/beta. I welcome any insight into making this process better. and I offer my help in updating/verifying whatever process or script you're using here, so that we can avoid hitting this again. I should also note, that if you feel the whole chatzilla thing is more trouble than its worth for you, and/or your users, we *can* abandon it all together (its not a hard requirement for our localization teams) we'd need to take a change to http://hg.mozilla.org/chatzilla/file/default/locales/all-locales on all shipping chatzilla branches, but thats easy to justify.
Thanks for the info. There's still something to fix here, but at least I'm good for this release and the next.
Flags: needinfo?(mozilla)
You need to log in before you can comment on or make changes to this bug.