Currently these two strings: * " wrote:" * "--- Original Message ---" are hardcoded in nsMsgCompose::CreateMessage() and QuotingOutputStreamListener::QuotingOutputStreamListener. They should both be put in a .properties file so they can be localizable.
I completely agree with reporter. All MUAs distributed on the french marked use "%s a écrit:" instead of "%s wrote:" for instance... Are these two the only 2 localizable strings ?
The strings are in the the mime.properties file. But for some reason they are not used. Ray, could you confirm? We decided not to translate the string in Japanese N6 (Please see bugscape bug 1797). Some mail clients also don't translate this, like Outlook Express.
Honestly though, do we want to be like Outlook Express? I think not. And I can't access Bugscape (because I'm no Netscape employee), so can you please conclude why we can't translate this to Japanese?
Kat, could you answer the question from firstname.lastname@example.org? Thanks.
More questions: why are the strings appended and hardcoded in C++? Why is the strings still there?
We should remove the strings to a properties file. Reassigned to ducarroz.
Assignee: rchen → ducarroz
> And I can't access Bugscape (because I'm no Netscape employee), > so can you please conclude why we can't translate this to > Japanese? It's not a matter of "cannot translate" but rather one of which would be better, to translate or not translate. In the case of Japanese, we decided during Communicator days that translating this string would mean that if you send a message in languages otehr than Japanese, you would be sending unreadable string in Japanese. On the other hand, ASCII string, "you wrote:", would be readable in messages of any language. This is the main reason why we chose not to translate the string. I think it's up to each localizer to decide whether or not this should be translated. Now if there is a way to use the translated string only when the message is in Japanese, we might do so. In fact, this might be a good thing to do. I don't think the current code distinguishes what string to use based on the language of messages.
That could be done I think easely by looking at the charset of the original message. Do we want to support more than english (or any iso-latin "language") and japanese?
J-F, it's not that easy for Western languages like French or German because all that the charset says is "ISO-8859-1". For Japanese, this might be easy but as a general code to handle any language message we support, I am not so sure. So, the question is what should be the spec for such a language switch and can we make a reasonable spec that covers not just a single language case but all of them.
I vote for leaving this untranslated for the moment if making it work correctly is going to be as complicated as it sounds. It sounds like 67504 is a dup of this.
Please note that I did not say that these strings should remain hard-coded. In fact I believe they should be translatable. The only suggestion I made is that if so, then in some languages like Japanese, we should not translate it. The other thing I would request is that when you extract these strings, don't break up a sentence: If you're going to extract "%s wrote: ", this whole thing should be one definition. Localizers then can choose not leave only "%s: " withoout translating "wrote". There are other ways in which localizers can translate or not translate this item.
It's OK for me to not translate to Japanese, but it should NOT be hardcoded either way. Let's move it to a .properties file and then argue about how to translate the best way.
I agree with making it localizable (if it's not already), but I wouldn't request the fix to detect each language in the next release. It'd be nice to have, but we can wait and there are other more critical bugs. My 2 cents.
IMO, if you touch this code, you should make the string entirely user-defineable. The user could then insert printf[-like] placeholders for "original author", "date" and whatever else we want to provide. I don't think, this is hard to code.
*** Bug 86404 has been marked as a duplicate of this bug. ***
*** Bug 89569 has been marked as a duplicate of this bug. ***
Comment from bug #89569: ------- Additional Comments From Frank Tang 2001-07-06 17:55 ------- see bug 75377 and http://lxr.mozilla.org/seamonkey/source/mailnews/compose/src/nsMsgCompose.cpp#14 60 I think we should not hard code that string. And in the localized build maybe we should use "%s :" instead of "%s worte:" or any translation of "wrote" No english is better than english in localized build.
Even if 'Name <e-mail>:' is used, this needs to be localizable. For example, in French, there should be a space before the colon: 'Name <e-mail> :'.
I hope you don't mind I take this bug.
Assignee: ducarroz → ftang
we can fix this bug in the following way, even break into several stages: Stage 1: 1. get the sending charset 2. convert the charset to langgroup1 3. get the current locale 4. convert the locale to langgrup2 5. if langgrup1 == langgrup2, use the localized string bundle 6. otherwise, use English (see Step 2 for improvement) for example, if we are on a German build and try to send ISO-8859-1 email 1. ISO-8859-1 2. ISO-8859-1 -> x-western 3. de 4. de -> x-western 5. x-western == x-western = > use German from the string bundle for example, if we are on a German build and try to send ISO-2022-JP email 1. ISO-2022-JP 2. ISO-2022-JP -> ja 3. de 4. de -> x-western 5. ja != x-western 6. use "wrote %s" Step 2: (replace 6 above) 7. Find the prefer language list from the preference 8. iterate through the language in the list 9. convert langupage to a langgrup3 10. if langgrup3 == langgrup1, get a translation from a locale-insensitive property file using the language as the key 11. if we have the translation of that langauge, use it 12. otherwise repeate step 8-10 13. after we run out of the list
Is "x-western" not overly broad? What, if I (de) am talking with a french guy?
ftang, this bug depends on bug 75377 (as does many other bugs). If you plan to fix this, please look into fixing that first. Thanks.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.4
But please. This should NOT be automagically localized. I do not want it to be in Spanish, just because I happen to sit on a computer in Spain. What I wnt is to be able to change it to whatever text i want, including a few "wildcards" like the realname, mailaddress, date and so on. So MY string can look like "John Doe <email@example.com> wrote: " While someone else might want it to be something like "So sprecht John Doe: ". Wouldn't this be just as easy, as trying to figure out how to say "John Doe wrote:" in 100 languages?
The strings are ONLY allowed to something other than english if that language pack is chosen. Even if I am on a Swedish system, the text should be in English unless I have the Swedish langpack.
too late for m9.4. move to m9.5
Target Milestone: mozilla0.9.4 → mozilla0.9.5
nsbranch- since Frank moved it to 0.9.5
Keywords: nsbranch → nsbranch-
move to m96
Target Milestone: mozilla0.9.5 → mozilla0.9.6
give nhotta to drive this issue and design
Assignee: ftang → nhotta
Status: ASSIGNED → NEW
cc to ducarroz
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Looks like we want to keep the English strings even if we provide localized string. So, make the strings localizable but keep English as default then provide UI to allow switching to the localized string (also allow editing the string). * English string can be remained hard coded or moved to .properties but tagging a note not to translate. * Add localizable strings to .properties. * Add pref items which may contain localized strings or user edited strings.
Created attachment 55310 [details] [diff] [review] Moved the hard coded reply header strings to pref so they can be editable.
I moved the reply header strings to pref so they can be editable. So UI may provide ways to set the strings (e.g. get strings from .property, provide editable widgets). Also added a locale string as a pref, this is used for date formatting. In future, we might be able to use locale to select strings from possible multiple locale packages. The pref string uses "%s wrote" so the order of the words can be changed. Also there is an option (by the type) to change the order of date string and author string. The patch has backend change only, it does not have changes for .property file and UI. Probably, we need a separate bug for UI.
*** Bug 31947 has been marked as a duplicate of this bug. ***
Comment on attachment 55310 [details] [diff] [review] Moved the hard coded reply header strings to pref so they can be editable. looks good. R=ducarroz
Attachment #55310 - Flags: review+
Nhotta, Are you confident this change won't slow down the time it takes to open a compose window?
It used to read one pref value "mailnews.reply_header_type". After the chage, it will read 7 pref values. I don't think that is significant. It is possible to read the header type and decide what other pref to load.
+ nsAutoString citePrefixDate; + nsAutoString citePrefixAuthor; + citePrefixDate.Truncate(0); + citePrefixAuthor.Truncate(0); why do you need to do truncate the strings? other than that, it looks fine. sr=sspitzer
Checked in, removed two lines. + citePrefixDate.Truncate(0); + citePrefixAuthor.Truncate(0); Filed bug 107884 for UI.
mark as fixed
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
*** Bug 75377 has been marked as a duplicate of this bug. ***
Filed bug 120870 for a backend implementation that makes reply read the string from .property file in case the user doesn't specify it in pref, so localization engineers can have a choice to localize those strings in localized builds.
Verified as fixed with a Ja build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.