Re: [Evolution-hackers] Language selection in composer

[Jan Krčál]

Not Zed wrote: On Tue, 2004-09-21 at 15:12 -0400, Jeffrey Stedfast wrote: On Tue, 2004-09-21 at 20:42 +0200, Jan KrÄÃl wrote: > Hi, > > I would like to implement this feature (bug #127530) there is no such bug # that I can find. the bug numbers only go up to ~68000 afaik. Gnome bugzilla jeff ... which you obviously worked out afterwards. Sorry for not saying it's a gnome bugzilla bug... > 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... what does this list of languages supposed to provide? other than "ooh, look. I have a menu dingus that I can click" without knowing what this language info will *actually* be used for, I can't help you... (the only language thing I can think of that'd be useful to have in the composer would be for providing hints in constructing the MIME message where there are numerous charset encodings that the strings could be encoded in - but generally these are limited to asian and cyrillic afaik) > > Second, I need to get strings from different locales (because of > changing those "On DATE, PERSON wrote:" labels). we plan to make this user-configurable, and not based on locale (altho currently it is based on the string the translator provides for your locale) Well the bounty says it should change based on the language you set. Making it user-configurable seems a much different problem, and one that hits user-interface issues otherwise it's too If you're writing to a french person it makes sense to change it to french, if you had a customised setting you'd have to customise it for each language you know, and it would still have to choose from one of those. It could still be an override, so isn't the same issue. Well, it could be still based on locale. If you customize it for some language, the results could be saved in gconf. Evolution would check if there is attribution for this language in gconf first and if not get the atrribution from locale afterwards. (I'm not sure I got your point, if you didn't mean this problem, just ignore following paragraph...) I don't think it's a big problem that the user would have to customize attribution for every language separately. How many languages such an average user speaks? ;-) > Should I do it using setlocale() before and after obtaining that > strings, or any other way? 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. 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? But FWIW. - I don't see why the spell checking language should be changed by any such setting, since mails could contain multiple languages. I think it's not usual to write one e-mail using multiple languages (in such case you would probably switch the spell-checker off). It's the problem of the spell-checker, not to check the quoted sections (that would most probably contain the other languages, if you have an e-mail in multiple languages), because there's no reason to correct someone other's typing errors. - I don't see where the 'language list' is defined or should be defined. This list makes the spell checking language list redudant, but they might not be able to match exactly. It should probably be part of some gnome-global locale (timezone) and preferred-language setting. - There seems no practical way to get the base attribution string translated to multiple languages. You'd probably have to list the language-specific string in the C file too, or use some pre-processing script to create it. - There isn't an easy way to even change the attribution text since it is just inserted into a stream at reply-creation time. You'd have to do something like the signature does, i guess that might work, but it will impact on more bits of code. (to the last remark) I know that I have to do it like the signatures, I don't think it's that complicated... Jan KrÄÃl _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers