666923 - When replying, the phrase "on date xyz abc wrote:" is translated wrong (type 2. vs 3. grammar conflict)

Status: RESOLVED FIXED

(MailNews Core :: Localization, defect)

Description

[Richard Prins]

User-Agent:       Mozilla/5.0 (iPod; U; CPU iPhone OS 4_3_3 like Mac OS X; nl-nl) AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8J2 Safari/6533.18.5
Build Identifier: 

This is a bug in the Dutch translation, but maybe also in other translations. The phrase is translated word for word, so the grammar is incorrect.

Reproducible: Always

Steps to Reproduce:
1.Open email
2.press reply
3.

Comment 1

[Tim Maks van den Broek [:mad_maks]]

This is not a localizationbug (see also https://bugzilla.mozilla.org/show_bug.cgi?id=549062#c22). We can not fix this.

maybe related to bug 450638?

Comment 2

[rsx11m]

From an independent but related discussion in http://gsfn.us/t/2bhki it seems that "Op [date] [time], [sender of the e-mail] schreef:" should be "Op [date] [time], schreef [sender of the e-mail]:", and you in fact could to that.

Changing mailnews.reply_header_authorwrote (which is "%s wrote" in en-US) to "schreef %s" you should get the correct ordering. On the other hand, bug 549062 comment #22 suggests that you are running into problems with the grammar when mailnews.reply_header_type is switched from 2 to 3, which indeed can't be solved with today's structure. Free templates are bug 107884.

Also bug 460646 indicates a similar problem in the [de] locale, thus the localization backend needs to be expanded to offer different "_authorwrote2" and "_authorwrote3" versions. This could be resolved by bug 107884, but that bug has stalled since, thus I wouldn't expect a generic solution soon.

-> REOPENING as MailNews Core bug

The other bug 450638 you refer to was opened to allow multiple localized strings, thus you can switch them when replying in one language or the other.

My suggestion for Richard would be to edit mailnews.reply_header_authorwrote locally in Thunderbird > Preferences > Advanced > General > Config Editor.

Comment 3

[Ton [:Tonnes]]

Back in januari this year I finally wrote a text in order to file a bug that might solve this issue for v.next and hopefully for once and for all, but left the action to file it (sorry…). We also discussed this about a year ago in a (Dutch) topic on mozbrowser.nl (http://www.mozbrowser.nl/forum/viewtopic.php?f=11&t=19429), as we did so earlier in one or more l10n bugs. Considering the fact there are several other bugs (like bug 460646, bug 576493, bug 450683 etc.) that are from 2008, there’s probably a big need but no action taken so far, though some bugs have different intentions. 

In short: I think the entire issue would be a matter of making default mailnews.reply_header_type and mailnews.reply_header_separator localizable, so they reside in the language files and could be set by the localizers, instead of having them fixed (and changed since TB 3.0!) for every locale. This is *not* quite the same as the goal of bug 450638, but merely a matter of having different default word orders after installation per locale. It seems to me this is easy to implement.

Do you want me to file it after all, or could we use this one?

Comment 4

[rsx11m]

(In reply to comment #3)
> In short: I think the entire issue would be a matter of making default
> mailnews.reply_header_type and mailnews.reply_header_separator localizable,

I don't know the exact mechanism as I'm not a localizer, but there should be some all-l10n.js override in the default preferences. The Swedish locale has used this mechanism to set type=3 as a default different from en-US's type=2 (see bug 485251). However, that won't solve the issue of different grammar and separators needed between type 2 and 3, but you may mitigate the problem.

To generally include the other prefs into composeMsgs.properties they'd need to be changed from GetUnicharPreferenceWithDefault() to its localized variant GetLocalizedUnicharPreferenceWithDefault() in the backend, where "type" is actually an integer value. But, in general, this would be solvable.

Comment 5

[rsx11m]

So, the most flexible scheme to resolve this IMO would be:
 - make the remaining mailnews.reply_header_* localized
 - keep mailnews.reply_header_authorwrote, etc., as the default for all types
 - allow optional mailnews.reply_header_*${type} as type-specific override

Thus, for the nl and de locales, and any others which may need that construct, you'd have reply_header_authorwrote2 as an extra localizable string. The caveat here is that all mailnews.reply_header_* would have to have empty defaults in both mailnews.js and composeMsgs.properties for all types so that they can be overridden by either localizers or the user. Considering possible bug 450638 extensions, this may imply that a significant amount of prefs would result by combinations of different locales and reply-header types. So, the all-l10n.js solution appears to be more attractive considering this issue, given that no default prefs and properties need to be defined; the pref names actually needed could be generated on the fly in nsMsgCompose.cpp's GetReplyHeaderInfo().

Comment 6

[Ton [:Tonnes]]

(In reply to comment #5)

Bug 485251 comment 5 hits the spot, as 460646 does. Our goal was primarily to use 1 or 3 (default) and make them both look nice without the need to change mailnews.reply_header_authorwrote.

> So, the most flexible scheme to resolve this IMO would be:
>  - make the remaining mailnews.reply_header_* localized
>  - keep mailnews.reply_header_authorwrote, etc., as the default for all types
>  - allow optional mailnews.reply_header_*${type} as type-specific override

Looks good to me. For nl (and de?), we could add them along with mailnews.reply_header_separator (space) in l10n-all.js for now.

Note that there is also bug 576493 that was marked duplicate, assuming this would get fixed in the referred l10n bug 549062, which never happened.

Comment 7

[Jack Brouwer]

Replacing the (comma) with a (space) in mailnews.reply_header_separator along with the changes written of in the above comments, I also have been thinking of since I had started this grammar topic in http://gsfn.us/t/2bhki. Nice!

Comment 9

[Tim Maks van den Broek [:mad_maks]]

This is fixed in Thunderbird beta 22