GNOME Bugzilla – Bug 621150
Add the possibility to modify locale of the quoting messages
Last modified: 2015-10-06 14:09:46 UTC
Created attachment 163234 [details] [review] The patch. I write most of the mail in English, but still, I want to use the UI in my native language. Unfortunately, the messages like 'On Wed, 2010-XX-YY, Foo Bar wrote:' are translated according to the UI language, which causes my mails to be a mixture of my native language with English. Attached patch adds a gconf entry that allows you to specify the locale of the quoting texts. I did not add any UI to be able to choose that, I am not sure if it is necessary, etc.
There's a typo in @@ -1587,7 +1621,7 @@ em_utils_send_receipt (CamelFolder *folder, CamelMimeMessage *message) Also, is LC_ALL necessary to change? I noticed some users are using different locale for times/dates than for texts. By the way, I'm not reviewing the patch, I cannot do such decision for evo.
Milan: Thanks for the comments! Not sure about the typo, I cannot spot it :-( The intention was not to change any of the translatable strings, but of course, I might have overlooked something. About LC_ALL - my intention was to overwrite anything by the setting, ie. if somebody had LC_ALL set, changing just LC_MESSAGES wouldn't be sufficient to overwrite the LC_ALL.
This seems somewhat non-thread-safe -- won't the quote_locale be applied to _everything_ that's translated during the period that the locale is changed? I think you may need to farm the 'other language' translations out to a separate process, or use a lock to prevent any other translations from occurring while you have changed the locale. OTOH, have you considered just running Evolution with LC_ALL=en? You don't seem to have a problem with using English :)
Created attachment 163786 [details] [review] Updated patch (don't modify the locale). David: Indeed, you are right about being non-thread safe, it has hit me just now (menu in English) :-( Hm... Using the UI in English is not really what I want, I like my native language ;-) I have converted to Evo from KMail, and there, you can configure the quoting strings as you need (for each and every identity - so you can have your native language identity, and English one too). But that is probably too heavy-weight. Anyway - some inspiration here, it would be indeed safer to have gconf entries for forwarded message ("-------- Forwarded Message --------"), and quote ("On ${AbbrevWeekdayName}, ${Year}-${Month}-${Day} at ${24Hour}:${Minute} ${TimeZone}, ${Sender} wrote:"), and use whatever is defined there if not empty. That would bring more freedom, and more safety too. Please check the attached patch, it implements the above-mentioned approach.
(In reply to comment #2) > Not sure about the typo, I cannot spot it :-( The typo was that you used there _, not N_, as everywhere else. But it doesn't matter now. You are leaking one byte in quoting_text when 'text' is an empty string, which seems to be a default. I didn't read this further, though I also do not like the way you define an array, it shouldn't be needed to use also "[QUOTING_ATTRIBUTION]=" and those other parts there. I'm also afraid that the "Translators:" comment will not be shown in the .po file, due to other string between that localized and the comment. Having there line number is sort of redundant and heavy, who will make it up to date on any changes in the file? :)
Created attachment 163793 [details] [review] Added g_free(). Milan: Updated patch with the missing g_free(), thanks for noticing! "[QUOTING_ATTRIBUTION]=" etc. is I believe just a matter of a personal taste, unless there is "no C99 in the Evo code!" in the coding standard. This makes it safer in case somebody decides to reorder the enum, but of course, I am not personally attached to that, feel free to cut that. gettext is smart enough, it does not care about strings that are not marked with _() or N_(). You are right that the line number is not a good idea, OTOH it must have been outdated already ages before my change ;-)
Ping?
Oh, I'm sorry, this got lost unintentionally on my side. :( The patch looks good. I fixed some minor things you didn't include in the last version, but nothing serious, thus I'm committing it. Thanks for your patience.
Created commit 89e3e02 in evo master (2.91.4+)
Milan: Great, thanks a lot! :-)
Thanks a lot Milan! I have been looking for this for ages!