Re: [Evolution-hackers] Language selection in composer

[Not Zed <notzed ximian com>]

Gnome bugzilla jeff ... which you obviously worked out afterwards.

Sorry for not saying it's a gnome bugzilla bug...

Its ok, we should be using that one anyway, but there's too much stuff to move just yet.

>  and I've got some essential questions that aren't related to any
> component, so I don't know, who should I address...
> 
> First of all, how can I retrieve the list of all languages available
> to the user? Should it be that languages that have evolution
> localization available (How can I determine which languages have
> evolution l10n? Should I go through $prefix/share/locale/ and find
> evolution-1.5.mo?) Or should it be just all languages that are defined
> in ISO 639 (Is there any other way than to hardcode it, than?).
> It seems usefull to have names of all languages localized to all
> languages (because evolution needs to show a list of available
> languages to the user). How can I get this?
    

I don't think you can.  You can get a list of locales, and you can get a list of the locales and possibly languages the user wants to see, but that isn't the same as a language list.

I think you would have to hard-code the list, and let the translators translate the language names appropriately.   Actually getting the translated attribution strings seems rather more difficult though.

I'm not sure 639 will suffice, since you need to take into account localisation, not just base language.  e.g. americans and their funny date format, vs the rest of the world.

There are two possibilities:
1. use hard-coded list
Than it would be better to use list of languages that have evolution localization instead of ISO 639. Is there any reason of listing a language that has no evolution localization?

2. use the list of locales
The handiest way IMO is to use libicu. It can output nice description of every locale (like "English (United States)") in your system's locale (actually, it's not translated to all languages). The advantage is that it would avoid duplicating of work (it would save translating some list of languages to every other language). The obvious drawback is that it need's libicu...

I say just go for a set-list of languages.  I guess you're going to have to have some sort of ui where you choose which ones are relevent to you (so you don't have all of them listed all the time in the immediate ui), and that same ui could let you add your own customisations.  I guess it would be possible to use the same mechanism just to customise it to be multivalued for any language too (e.g. 'friends' vs 'work'), but that might be verging on scope-creep (especially since then you'd want to have the value change depending on who you're replying to, or at least based on account, etc).

You can't change the locale, because evolution is a mutli-threaded application and it could break things.

I think, the best way would be to run another process (that would just change to desired locale and get the translation) and somehow communicate the results.

I don't really like that idea either.

If you put the string into an xml file, then the xml i18n tool will expand all the translations into the file and they can be iterated through in code.  That might be the easiest way to integrate with the translators and provide customisation.  If you're going to save your own copy you're going to need the some way to save them anyway and the formats could be similar.

no, do not do this.

anyways, I have no idea what you are trying to solve so I can't really
help you.
    

The ximian bug has more info, which wasn't hard to find.

I'm not really convinced this entire idea is all that practical anyway, or even a very good idea.

I don't think it's that bad ;-)  But if you (or somebody else at novell) dicide that this feature shouldn't get implemented, I won't do it. (what would be the motivation to write a path, which has no chance to get accepted?) But why is there a bounty for this feature, than?

I'm not sure how everything on the bounty list was come up with.

But I guess if it can be done nicely and work unobtrusively it should be fine, and we'll certainly accept the patch.  To me it seems a bit bloaty, but it could be useful for some people.