Celestia Forums

This is also reported to SourceForge as [ celestia-Bugs-2753461 ]

Platform : Windows XP
Version : SVN 1.6.0 version whichi is built. Same symptom with 1.5.1
Hardware : ATI Radeon X1300PRO + Intel Core 2

Korean language is shown properly before initiating image capture using File-> Image capture. (Refer "Catpure with Windows")

When "Save as" dialog is activated and moved, target information displayed left top of windows is changed into English. Saved image also contains English version target information. (Refer "Catpure with Celestia")

After saving, the information is returned to Korean. (Refer "Catpure with Windows")

Seung-Bum,

I can indeed reproduce this issue using the French locale.
Like you, I noticed that when I close the Capture Image dialog,
and re-open it, then the overlay text is correctly translated.
This is true as long as the Capture Image dialog is not moved.
As soon as it is moved, the overlay text get back displayed in
English.

I'll work on a fix for this.

edit: The same issue applies to the movie record dialog.

PS: When reporting a bug, it is recommended to disable the Lua Tools
(Shift+I or click on the right hand of the toolbox) to avoid confusion about
the origin of the bug. In the present case, it also makes it easier to focus
on the standard information text which is related to the bug.

Vincent,

Thank you. And I will do as you recommended (Turning off Lua Edu tools).

Seung-Bum

This is not happening in Linux (Ubunutu 9.04 with SVN version).

I've been investigating this bug for a couple of days, but haven't found a fix yet.
It looks like gettext can't find the translated strings anymore as soon as the "Capture
Image" dialog is opened, although the language is still set to the system locale. This is
also true with the "Capture Movie" and the "Open Script" dialogs. I'm pretty sure that
it has something to do with the OPENFILENAME structure (MSDN library). Meanwhile,
one can close the dialog and re-open it a second time. If the dialog is not moved,
then the overlay text is correctly translated using the system locale.

What I also found is GetOpenFileName (and maybe GetSaveFileName) changes locale information.

Please, refer http://www.tech-archive.net/Archive/VC/ ... 00456.html

One thing might be possible is to store texts which needed to be printed on OpenGL screen and print when screen updates.

This might keep the proper strings. When you see the name of objects, it is not changing and this may support this idea, too.

sblee wrote:What I also found is GetOpenFileName (and maybe GetSaveFileName) changes locale information.

Please, refer http://www.tech-archive.net/Archive/VC/ ... 00456.html

One thing might be possible is to store texts which needed to be printed on OpenGL screen and print when screen updates.

This might keep the proper strings. When you see the name of objects, it is not changing and this may support this idea, too.

As far as I've investigated, GetOpenFileName and GetSaveFileName don't change the language setting.
On my system, when opening the Image Capture dialog, the language is still set to "French" which corresponds
to my system locale. That's why the name of objects is still correctly translated.
The problem is that although the language is still set to French, gettext doesn't seem to be working anymore.
Storing all translated strings would indeed fix the problem, but this would require a lot of changes in the internationalization
code. And I'm not sure it is worth it since the incoming Qt4 version won't have this problem - I've already checked this out.

Ok, I've finally figured out this issue. The problem comes from the bindtextdomain call in the gettext
integration code (winmain.cpp, line ~3300). The "locale" directory, where all the translation files are
located, is defined using a relative path to the directory of the current process. When calling
OPENFILENAME, the current directory changes to the root of the user’s profile (%userprofile%).
That's why gettext can't find the "locale" dir anymore. So the fix simply consists in storing the celestia
application path, and then using it as an absolute path in the bindextdomain call. That's what the
following patch does: http://vincent.giangiulio.perso.sfr.fr/ ... _patch.zip

The problem is fixed with your patch.

Thank you.

sblee wrote:The problem is fixed with your patch.

Thank you.

Seung-Bum,

You're welcome. This fix will go into 1.6.1.