On Friday 21 March 2008 10:14:09 pm Julien Kerihuel wrote:
> On Fri, 2008-03-21 at 14:42 +1100, Brad Hards wrote:
> > Small Business Server 2003 SP2 (which is basically exchange 2003 SP2, if
> > I understand it correctly) wants to speak french to me. That is
> > unfortunate, because I'm monolingual.
> >
> > I've added an option to mapiprofile to allow you to specify the language
> > code to use, instead of always defaulting to 0x40C (which is fr-FR). We
> > now default to en-US, and you use the --langcode option to specify
> > something else.
>
> The patch sounds good to me. However, maybe can we improve the option
> and parse the lcid argument so it either takes an hexadecimal value or a
> language name (string).
I've added this part. If it isn't valid, it defaults to en-US - see below.
> IIRC libmapi/util/locale.c relies on values from Windows Language Code
> Identifier (LCID) Reference. If input argument is not hexadecimal, then
> check for locale_struct locales[] locale_str and if partial match
> (strncasecmp using input string length) is found, then return the
> associated lcid.
I got a bit concerned while testing this. It turns out that is is really easy
to get the name wrong (since the format is a bit specific to Openchange: e.g.
English_Australian). So what I've done is to make --listlangs provide a list
of valid languages, and it has to be an exact match (or we fall back to
en-US).
Questions:
1 . Should a bad language name be an error (instead of falling back to en-US)?
2. Do you still want to do a substring match (so, for example, French will
produce French_Standard)? I can add that quite easily.
3. Is there a way to guess a "sane" codepage and method from the language
code. I see something that looks possible ("combinations" in the locales[]
structure), but I don't understand it. Basically, I'm looking to replace
this:
mapi_profile_add_string_attr(profname, "codepage", "0x4e4");
mapi_profile_add_string_attr(profname, "method", "0x409");
Brad
_______________________________________________
devel mailing list
[email protected]
http://mailman.openchange.org/listinfo/devel
