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
|
