MSVC ?

[Mattn]

both are not known - have you compiled the po files? (from within c::b or compile_po.bat in contrib/scripts)
any console output for the second error? do you have the maps compiled?

[Duke]

NO to both po and maps.

A brief test after executing po.bat showed that it didn't solve the i18n prob. Will retest later.
Currently compiling the maps...

btw I added the info you gave above to the 'prepackaged C::B' chapter in the wiki. plz review.

[geever]

Is the entire game German or just some texts? Is German your machine's default locale?
This smells like locale glitch.

-geever

[Duke]

True. Machine's default locale is german.
But it's a little different than in that bug report you linked.
The game seems to be >90% german. The rest might well be strings where i18n is not (yet) implemented.

I even switched to 'danish' in the options menu, but to no avail.

[Duke]

I finally finished compiling the maps.

Congrats, you had the right idea
The 'einzelgefecht' now works fine.
The i18n prob persists, though.

[RudolfoWood]

did you try to restart game after changing language? As stated in the bugreport some texts are translated on startup and stay so until language is changed. This mainly applies to weapons.

Another version is related to saving: messages are saved in its translated version, so switching to another version and loading a savegame displays old messages with old language settings

[Kildor]

RudolfoWood, this doesn`t help.

[Duke]

Current situation is:
The freshly started exe comes up and has 'remembered' that the language switch is set to danish. All menus, buttons, item desc etc. are in german.
I chose danish to prove that it's neither the default nor the machine's locale.

[Duke]

Update:
I'm not yet familiar with the ufo code nor with language handling. But the snippit from CL_LanguageTryToSet() below looks rather strange to me:

Code: [Select]

do {
Cvar_Set("s_language", mapping->localeMapping);
#ifdef _WIN32
Com_DPrintf(DEBUG_CLIENT, "CL_LanguageTryToSet: %s\n", mapping->localeMapping);
SDL_putenv(va("LANGUAGE=%s", mapping->localeMapping));
Cvar_Set("s_language", language->localeID);
s_language->modified = qfalse;
return qtrue;
#else
if (setlocale(LC_MESSAGES, mapping->localeMapping)) {
Cvar_Set("s_language", language->localeID);
s_language->modified = qfalse;
return qtrue;
}
#endif
mapping = mapping->next;
} while (mapping);
#ifndef _WIN32
Com_DPrintf(DEBUG_CLIENT, "CL_LanguageTryToSet: Finally try: '%s'\n", localeID);
setlocale(LC_MESSAGES, localeID);
#endif


On WIN32, the do-while will always break after the first loop AND return, so
1. the #ifndef _WIN32 after the while is useless (not the enclosed code)
2. setlocale() is never executed here on WIN32

So as the function behaves *completely* different on WIN32, I would expext a big fat comment stating that.
The missing of such a comment along with the useless #ifndef lets me suspect that the code does not work as the programmer intended.

Anyone around who knows more about how setlocale should work on WIN32 ??

[Duke]

Uhmm...forget about my above post (exept for the missing comment and the useless #ifndef), that is NOT the error.

After some research and debugging, I have been able to nail it down to this:

Code: [Select]

// SDL_putenv(va("LANGUAGE=%s", mapping->localeMapping));  // does NOT work on Win
putenv(va("LANGUAGE=%s", mapping->localeMapping));      // works fine here

What I have not figured out is how SDL_putenv() is superior to putenv(). Back in 2.2.1 Q_putenv() was used (and worked fine).

I also found this on the web:
"Not all environments have a working putenv(). SDL_putenv() is not available on Windows. "
(from : http://docs.taoframework.com/Tao.Sdl/Tao.Sdl.Sdl.SDL_putenv.html)

[Amtep]

Hmm. Q_putenv() went out of its way to call setenv() on "APPLE" and putenv() on other platforms. Linux also has setenv() nowadays; perhaps Windows does too?

setenv() is better than putenv() because putenv() keeps the string and makes it part of the environment. That means that Q_putenv()'s approach of constructing putenv()'s argument in a local string is bound to fail: as soon as that memory gets overwritten, the environment string gets overwritten.

If we can use setenv() everywhere, we should.

[Duke]

Just tested it: setenv() doesn't exist on Windows

Why don't we just create some UFO_setenv() and therein do whatever is necessary for the various platforms supported ?

[Duke]

Amtep, I can hardly believe what you said about putenv(). Are you really saying it stores a pointer of unknown origin in a semi-permanent structure like the environment and not creating a copy
Or did I simply not understand you ?

That's a common newbie fault, but no C-programmer with a sane mind and more than 2 weeks of coding experience would do that imho.

At least the putenv implementation in Windows doesn't seem to have that problem.

-----

Ok, so SDL_putenv was introduced to support APPLE. The line of code in question is already enlosed in #ifdef WIN32. So we can safely change that line to a simple putenv() without disturbing the other platforms.
The dowside is, that we then no longer have just one function that encapsulates the stuff. But as SDL_putenv() is only called from a handfull of places, all in the context of locale setting, which needs a lot of #ifdef's anyway, I think we can afford that.

[Amtep]

Yep, it really behaves that way. What's more, it was standardized that way, so even platforms which used to make a copy now keep the string instead. The standard is here, but a web search for "putenv man page" will find similar language for a variety of platforms. Windows seems to be the big exception here, actually, probably because it has a different structure for keeping track of the environment and it needs to copy the value to that.

If Windows doesn't have setenv, then using putenv on Windows and setenv everywhere else seems to be the way to go. If it's all inside an #ifdef WIN32 then you're probably right that we don't need a helper function.

[Duke]

Amtep, thanks a lot for providing the link to the standard. As you probably guessed from what I wrote above: otherwise I wouldn't have believed you.
I always thought of 'the environment' as a way to pass some kinda configuration to programs. Obviously, the opengroup guys had something different in mind; like a cheap way to pass data between threads.
Ok, we're not here to judge the decisions of standardisation organisations...

----

As we both seem to agree on the solution of our little language problem and I don't have commit access to the svn, may I ask you to commit the fix ? Unless some 3rd person objects, of course.
I forgot to mention that the line in question is located in module cl_language.c, func CL_LanguageTryToSet(),
somewhere around EOF minus 20 lines.
For a 4-byte change, a diff would be overkill, right ?
Oh, and you may want to add this comment:
/* as SDL_putenv() doesn't work on Windows, we need to use putenv() here */
Ok, more than 4 bytes....