*** bug 212770 has been marked as a duplicate of this bug. ***

In addition to this pop-up menu there ought to be a per-domain based
language selection feature as described in bug 212770 (not really a
duplicate IMHO). The pop-up menu would OTOH be a perfect complement to
that feature.

*** bug 213747 has been marked as a duplicate of this bug. ***

The mockup shows that the language/country can be chosen by clicking
on an image of 'flag'. Recently, there was a spate of mails in the
news group regarding the political nature of shipping flags. The
discussion ended with the members confirming that no flags will be
shipped with Gnome. In view of this, what can be used in liu of the
'flag' selection box for country/language ?

cc: our UI and art guys, but they're both on vacation right now,
so don't expect any ideas from them until after new year's.

One solution might be to have the menu be an icon that generically
represents language somehow, and when you pop it up, it just has
language names rather than icons.

Dan is right. Although a complete set of flags is not kosher for
political reasons, a single icon config_language.png shipped in
gnome-icon-theme should be used in the toolbar as the mockup shows.

Also note the http://bugzilla.ximian.com/show_bug.cgi?id=127812 that deals with the proper way to use icons
in future. The mess in art/ is going away.

About the string, "On DATE, PERSON wrote:",

gettext depends on POSIX locale value.  So the only way for a process
to retrieve various languages translations of a given msgid is,
changing POSIX locale. But changing locales with setlocale()
before/after gettext() is never thread-safe.

1. If Evolution is not (and will not) using multi-threads, it can just
use setlocale() before/after gettext().  But I guess it could cause
problems if the composer is used by other programs as a component.

2. Modifying or forking gettext is another solution.  But it might
take a long time.

3. Calling another process with different LANG envvar is, IMHO, the
only feasible solution now.  For example, popen("LANG=ll gettext
evolution 'On %s, %s wrote:'")

Changwoo: huh? what are you talking about? I don't see how gettext has
anything to do with this bug?

Sorry.  My English's poor.

This is just a possible problem when implementing the language popup
menu.  When a language is selected from the language pop-up menu, then
the "On_DATE,_PERSON_wrote:" string has to be written in the chosen
language, like the mockup screenshot, right?  Then it is required to
retrieve gettext translation of the chosen language.

I said, gettext() is not suitable for this purpose, because the target
language can't be selected without changing global (thread unsafe)
POSIX locale.

a quick back reference to the same one at
<http://www.gnome.org/bounties/Mailer.html#127530>.
if one gets solved, close the other one :-)

If the "on date someone wrote" string should not be effected by this
(See http://bugzilla.gnome.org/show_bug.cgi?id=127530), then basically
the only user-visible thing left is the spell checking language: The
"Forwared message" string is so minor that I personally don't think it
is worth introducing the popup for. 

Just taking the Content-Language header, and then using that to set
the spell check language in the composer would seem like a better
solution. But this is problematic, take for example this case:

Somebody runs evo in a Swedish locale and then sends a message to a
Gnome mailing list. The Content-Language header is set to Swedish, as
the Swede doesn't bother to select a different language just for
typing a message. Then another Swede replies, and then the spell check
language is suddenly set to Swedish, and suddenly everything he types
in perfectly valid English is marked as misspelled. Bork.

still missing in 2.7.3.

Bumping version to a stable release.

Andre, do you recall if there were any mockups for that bounty you mentioned four years ago?  The link is dead now.  The composer is already getting a facelift for 2.24, so now is a good time to investigate enhancements like this.

*** Bug 127530 has been marked as a duplicate of this bug. ***

This bounty was available in 2003 and is not available anymore. 
Closing as OBSOLETE.

*** Bug 694066 has been marked as a duplicate of this bug. ***

I disagree with Jeffrey Stedfast  on bug 127530#c4 that the attribution string should not change. Of course, if you have a custom composer-message-attribution on org.gnome.evolution.mail, it shouldn't change, but on the default case where it is loaded from the UI language, it should.

The language of the email messages is different than UI language. It's not uncommon to use one language for the UI (in your mother tongue, or perhaps in a foreign language you're learning) but have most of your mail in a different language.
As a workaround, you can set composer-message-attribution with dconf-editor to a custom string appropiate for most of your emails. And change the rest manually.

This is related to bug #228772 and bug #561799

Changing the attribution text once it's part of the composer body is problematic. Users can change it, it can wrap, the information from the original message is lost. Thus I'd rather skip it.

The selection of the attribution language per account can be done since bug #228772 and it adds also that language for spell-checking, if available.

As there can be multiple languages selected for spell-checking, I'd not use the spell-checker as the place to get the Content-Language header from. Neither I'd use this header value of the original message to preselect anything in the composer. Also due to reasons outlined in comment #11.

I'm afraid we cannot do the code that smart to cover all the cases. How much faulty it would be is hard to guess.

In any case, I'm closing this in favor of bug #228772.