Closed Bug 601583 Opened 14 years ago Closed 14 years ago

[sl] issues with tb31x sign-off on a1efdd3bbf13

Categories

(Mozilla Localizations :: sl / Slovene, defect)

Product:
Mozilla Localizations
Component:
sl / Slovene
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: Pike, Assigned: smolejv)

Details

I did a review of https://l10n-stage-sj.mozilla.org/shipping/diff?tree=tb31x&locale=sl&from=016add3b2685&repo=releases/l10n-mozilla-1.9.2/sl&url=http://hg.mozilla.org/releases/l10n-mozilla-1.9.2/sl/&to=a1efdd3bbf13 and came across some regressions and some things where I'd prefer help on the review:

http://hg.mozilla.org/releases/l10n-mozilla-1.9.2/sl/diff/f791b41b8768/mail/chrome/messenger/messenger.properties#l1.153 breaks mailAcctType.

I'm pretty sure that in http://hg.mozilla.org/releases/l10n-mozilla-1.9.2/sl/diff/8841302c4801/mail/chrome/messenger/messengercompose/messengercompose.dtd#l1.58, the .key2 entities should remain VK_F3.

The localization notes around BCC and friends make me wonder about
http://hg.mozilla.org/releases/l10n-mozilla-1.9.2/sl/diff/f791b41b8768/mail/chrome/messenger/mime.properties
http://hg.mozilla.org/releases/l10n-mozilla-1.9.2/sl/diff/ff4b54422eb7/mail/chrome/messenger/mime.properties
http://hg.mozilla.org/releases/l10n-mozilla-1.9.2/sl/diff/f791b41b8768/mail/chrome/messenger/mimeheader.properties
http://hg.mozilla.org/releases/l10n-mozilla-1.9.2/sl/diff/ff4b54422eb7/mail/chrome/messenger/mimeheader.properties

Can someone from mail help out?

The removal of \n\n within desc in http://hg.mozilla.org/releases/l10n-mozilla-1.9.2/sl/diff/f394afb05964/mail/chrome/messenger/offlineStartup.properties should be undone, I guess.

http://hg.mozilla.org/releases/l10n-mozilla-1.9.2/sl/diff/8841302c4801/mail/chrome/messenger/quickFilterBar.dtd changes the description for find find_cmd to T, but I can't find a command key that matches that. Could very well be that I only found wrong ones.

In particular the first one is a regression that we shouldn't take, the second one as well. Can't triage the mime ones. Rejecting the sign-off based on the comments here.
http://hg.mozilla.org/releases/l10n-mozilla-1.9.2/sl/diff/f791b41b8768/mail/chrome/messenger/messenger.properties#l1.153 is definitely wrong.

Re the BCC and friends, the text is used when you do a forward inline, and we put an html table at the top of the forwarded message, with the original message's subject, to, cc, etc headers. What looks odd to me in the code is that if the user is using the plain text compose window, we don't localize the headers at all, but for html, we do. I don't know of any technical reason that the localizer can't translate those html table entries however they want, i.e., I suspect the localization comment is wrong. I'd be curious what other localizations are already doing. Maybe there's some code or extensions that look at that html table, but I kinda doubt it.
Starting from the top ...
First, very much thanks to Axel for his contribution. I am sorely missing Sipaq as anybody else is, and this should be remedied as soon as possible. I have tried (with my group of three) to do as much as possible by myself, but then 2 extra eyes (at least) are absolutely essential ...

Back to Axel: can I do this kind of analysis myself - iow  was the analysis some variant of compare-locales? 

Now to the points
A) .../messenger.properties#l1.153 - to be fixed asap

B) the .key2 entities should remain VK_F3. - to be fixed asap

C) CC and BCC issue: in 3.0 we followed the DO NOT TRANSLATE comment, to get flamed and ridiculed by users ("...it spells BCC, so it should be easy to find..."). So I decided to localize it, in spite of the warning, and wait to see what happens - not exactly a sound strategy, I admit.

I talked to Dasher about it in Whistler and of course he had no idea what I was talking about. The correct way to handle the issue would probably have been to stick to  DO NOT TRANSLATE and at the same time enter a bug. It IS a bug or at least a hack: it's like asking NOT to localize "File" string in the menu.

...removal of \n\n to be undone - to be fixed

...changes the description for find find_cmd to T,  - without knowing the context, it should either be I or something link Ctrl+F - to be checked

Bottomline: maybe it would make sense to fork the bbc issue, so that the rest can be fixed independently and the bug closed - which I hope would remove the blocker status.

Please advise.

smo

PS: "Maybe there's some code or extensions that look at that html table, but I kinda doubt it." Occam#s razor: it's an artifact.
Assignee: nobody → smolejv
The only tool I used was my pretty-diff tool across multiple revisions, I linked to that from the top. You can also get to it through https://l10n-stage-sj.mozilla.org/pushes/?length=50&repo=%2Fsl. And then it's just tedious. I've got my eyes trained a bit to skip things that are safe and things that may not, but that's it. Anything that's changing that looks like format, I investigate. In this case, it was quite a lot, and I probably spent some 20-30 mins going through and investigating, checking in with en-US, finding useful links etc.

I'm fine with forking the BCC issue.
Axel, I really appreciate. pretty-diff tool you say ...

I have fixed points A, B, D and E in the mean time:
http://hg.mozilla.org/releases/l10n-mozilla-1.9.2/sl/rev

The changeset, you have spent quite some time with, cost me about 20 hours of my life. It has to do with shortcuts and this involves contexts and searches and and and, I guess you know what I am talking about. 

And of course the shortcuts is what users have been complaining about since 3.0x.

Standing by.
Status: NEW → ASSIGNED
new bug created for BCC issue - 603438
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.