First ES translation patch and something else

[Ernesto Domato]

Well, here goes my first two patches for crimson field. The first one
implements the translations to Spanish of the engine and units, later
I'll send the patches for the levels. The second patch is optional and
it implements the functionality that if you start the game for the
first time, so the configuration file doesn't exists yet, it display
the "Language Selection" windows so you can choose with language you
want to use. I did this because at least in my country is usual that
players doesn't understand a bit of english and it could be difficult
for them to change the game to spanish easily.

What do you think about this implementation?

Regards,
Ernesto.

[Константинов Юра]

I guess, it'd be good to include this language selector patch to next official release.
And... Why doesn't the Windows port save the resolution/screen mode settings? It's quite annoying.

[Nikola Smolenski]

Post by Ernesto Domato
I'll send the patches for the levels. The second patch is optional and
it implements the functionality that if you start the game for the
first time, so the configuration file doesn't exists yet, it display
the "Language Selection" windows so you can choose with language you
want to use. I did this because at least in my country is usual that

For another game I made (never implemented) a patch that reads the
system locale, perhaps that would be even better. I could adapt it for
CF if Jens approves.

[Ernesto Domato]

Post by Nikola Smolenski

Post by Ernesto Domato
I'll send the patches for the levels. The second patch is optional and
it implements the functionality that if you start the game for the
first time, so the configuration file doesn't exists yet, it display
the "Language Selection" windows so you can choose with language you
want to use. I did this because at least in my country is usual that

For another game I made (never implemented) a patch that reads the
system locale, perhaps that would be even better. I could adapt it for
CF if Jens approves.

Yeah, I know that. Did you do it cross-platform?, because I have no
experience programming for other platform other than Linux and I'd
like to see how you managed it. Maybe we could make an hybrid that if
no locale is defined on the configuration file it tries to get it from
the system locale and if that fails too, it could use my approach.

For example, I see a problem on the GP2X (I have one) were you don't
configure a locale but as it runs Linux, I guess that the system
locale will always be english. In this case the hybrid approach will
probably fail too.

Ernesto.

[Henk Jonas]

Setting default to sys language (if defined) and show the language selector as first at start.

-- Gesendet von meinem Palm Prē

Post by Nikola Smolenski

Post by Ernesto Domato
I'll send the patches for the levels. The second patch is optional and
it implements the functionality that if you start the game for the
first time, so the configuration file doesn't exists yet, it display
the "Language Selection" windows so you can choose with language you
want to use. I did this because at least in my country is usual that

For another game I made (never implemented) a patch that reads the
system locale, perhaps that would be even better. I could adapt it for
CF if Jens approves.

Yeah, I know that. Did you do it cross-platform?, because I have no

experience programming for other platform other than Linux and I'd

like to see how you managed it. Maybe we could make an hybrid that if

no locale is defined on the configuration file it tries to get it from

the system locale and if that fails too, it could use my approach.



For example, I see a problem on the GP2X (I have one) were you don't

configure a locale but as it runs Linux, I guess that the system

locale will always be english. In this case the hybrid approach will

probably fail too.



Ernesto.

[Jens Granseuer]

Post by Henk Jonas
Setting default to sys language (if defined) and show the language
selector as first at start.

Yeah, I guess that would be best (albeit a tad annoying on systems where
the locale *is* set properly). There probably is no universal way to
figure out the current locale for all systems we currently support but
we can add additional systems as needed. Just make sure the default
implementation returns English when it doesn't know and we should be
fine.

Jens

[Nikola Smolenski]

Post by Ernesto Domato

Post by Nikola Smolenski
For another game I made (never implemented) a patch that reads the
system locale, perhaps that would be even better. I could adapt it for
CF if Jens approves.

Yeah, I know that. Did you do it cross-platform?, because I have no
experience programming for other platform other than Linux and I'd
like to see how you managed it. Maybe we could make an hybrid that if
no locale is defined on the configuration file it tries to get it from
the system locale and if that fails too, it could use my approach.

Well, it is cross-platform in that it works properly with KDE and Gnome, but
other than that, no. I don't know how to do it on Windows, and of course have
no idea how to do it on embedded systems.

// Find the user's preferred language
// @author Nikola Smolenski <smolensk-***@public.gmane.org>
// TODO: Windows, Mac

char strDesktopLang[64] = "", *t;

// Desktop environment detection done according to
// http://flyback.googlecode.com/svn/trunk/src/desktop.py
if(getenv("KDE_FULL_SESSION") || getenv("KDE_MULTIHEAD")) {
// We're in KDE! Language detection done according to
// http://faqs.pcbsd.org/index.php?action=artikel&id=332
if(fDesktopConfig.Load(JString(getenv("HOME"))
+ "/.kde/share/config/kdeglobals", "rb")) {
while(fDesktopConfig.NextLine()) {
sscanf(fDesktopConfig.GetPos(), "Language = %63s", strDesktopLang);
if(strDesktopLang[0]) break;
}
}
}

if(!strDesktopLang[0]) {
// If we're not in KDE or haven't found the language
// there, try ~/.dmrc (it should be common across DEs)
if(fDesktopConfig.Load(JString(getenv("HOME")) + "/.dmrc", "rb")) {
while(fDesktopConfig.NextLine()) {
sscanf(fDesktopConfig.GetPos(), "Language = %63s", strDesktopLang);
if(strDesktopLang[0]) break;
}
}
}

if(!strDesktopLang[0]) {
// If that didn't work, at least try $LANG
strncpy(strDesktopLang, getenv("LANG"), 63);
}

// Cut off country code if it exists
t = strchr(strDesktopLang, '_');
if(t) *t = '\0';

[Константинов Юра]

For a good coder, it should not be a problem to compile a qt application with a different keyboard/pointer recognition on an embedded system, while on Windows it won't even require hardware recognition modification - only thing required is to compile it properly. And, speaking of one ED (Sharp Zaurus), I guess it's better not to try compiling for ZaurusOS - port the game on MobLin (a Linux OS for Zaurus). Idk on which Zaurus model you're trying to do it, but I know that about half of Zaurus family uses a PDA-type kboard instead of a phone one. I think that could ease porting CF for those devices. As i see this branch of "another game" starts to overwhelm the "ES translation" topic, let's just branch the "another game" topic not to spam this category

[Jens Granseuer]

Post by Nikola Smolenski

Post by Ernesto Domato
Yeah, I know that. Did you do it cross-platform?, because I have no
experience programming for other platform other than Linux and I'd
like to see how you managed it.

[...]

Post by Nikola Smolenski
Well, it is cross-platform in that it works properly with KDE and Gnome, but
other than that, no. I don't know how to do it on Windows, and of course have
no idea how to do it on embedded systems.

Well, different Linux desktops certainly isn't cross-platform. It's not
too big of a deal, though, since we can actually implement language
detection on a per-platform basis as needed. In any case, no platform
will be worse off than it is right now.

[...]

Post by Nikola Smolenski
// Desktop environment detection done according to
// http://flyback.googlecode.com/svn/trunk/src/desktop.py
if(getenv("KDE_FULL_SESSION") || getenv("KDE_MULTIHEAD")) {

Eek! Now that's horrible! Even if we add per-platform code I certainly
don't want per-desktop code in there. I don't know how KDE does stuff,
but Gnome uses LANG and LC_* just like any other UNIX platform should.
That's basically the *only* approach I consider sane on UNIX systems.
Anything else will result in a horrible mess.

Jens

[Константинов Юра]

Heh? CF uses QT - just like KDE. So WTF is all the "qt=not x-platform" about? If it's anyhow QT-based/QT-compatible, then it is likely that (at least) the app would work on BSD/NIX/LINUX - and if the programming language is win32-compatible, then only a few tweaks could be needed to compile under Win32. I'm an obsessed gamer, so idk much about NIXes/BSDs. Let me know if the game can be translated to more sl languages by using the font that is here for српски language (the bottom language in the menu). One letter to be put into the "extra letters" is a letter, which in upper-case looks like "bl" - then the game could be translated to more sl languages (including Russian - русский).
I hope, UbiSoft won't capture the project when reaching 1.0 - that'd be awful. Imagine this: "To download Crimson Fields 1.1.01a you must purchase any 4 UbiSoft products from the web or enter their CD keys." - that'd be shitting dumb. (UbiSoft purchased the Blue Byte Software)...

[Ernesto Domato]

Post by Константинов Юра
Heh? CF uses QT - just like KDE. So WTF is all the "qt=not x-platform" about? If it's anyhow QT-based/QT-compatible, then it is likely that (at least) the app would work on BSD/NIX/LINUX - and if the programming language is win32-compatible, then only a few tweaks could be needed to compile under Win32. I'm an obsessed gamer, so idk much about NIXes/BSDs. Let me know if the game can be translated to more sl languages by using the font that is here for српски language (the bottom language in the menu). One letter to be put into the "extra letters" is a letter, which in upper-case looks like "bl" - then the game could be translated to more sl languages (including Russian - русский).
I hope, UbiSoft won't capture the project when reaching 1.0 - that'd be awful. Imagine this: "To download Crimson Fields 1.1.01a you must purchase any 4 UbiSoft products from the web or enter their CD keys." - that'd be shitting dumb. (UbiSoft purchased the Blue Byte Software)...

Just to let you know, CF doesn't use QT, it uses SDL and for that
reason it's able to run in so many platform and architectures. So
please don't make any affirmation if you are not really sure about
what you're talking about.

Regards,
Ernesto.

[Albert Vest]

Post by Ernesto Domato

Post by Константинов Юра
Heh? CF uses QT - just like KDE. So WTF is all the "qt=not x-platform" about? If it's anyhow QT-based/QT-compatible, then it is likely that (at least) the app would work on BSD/NIX/LINUX - and if the programming language is win32-compatible, then only a few tweaks could be needed to compile under Win32. I'm an obsessed gamer, so idk much about NIXes/BSDs. Let me know if the game can be translated to more sl languages by using the font that is here for српски language (the bottom language in the menu). One letter to be put into the "extra letters" is a letter, which in upper-case looks like "bl" - then the game could be translated to more sl languages (including Russian - русский).
I hope, UbiSoft won't capture the project when reaching 1.0 - that'd be awful. Imagine this: "To download Crimson Fields 1.1.01a you must purchase any 4 UbiSoft products from the web or enter their CD keys." - that'd be shitting dumb. (UbiSoft purchased the Blue Byte Software)...

Just to let you know, CF doesn't use QT, it uses SDL and for that
reason it's able to run in so many platform and architectures. So
please don't make any affirmation if you are not really sure about
what you're talking about.
Regards,
Ernesto.

Just as a fact check, here is the dependency list copied verbatim from
my freebsd system.

discovery# pkg_info -r crimson\*
Information for crimson-0.5.3:

Depends on:
Dependency: xineramaproto-1.1.2
Dependency: xf86vidmodeproto-2.2.2
Dependency: xf86dgaproto-2.0.3
Dependency: xextproto-7.0.5
Dependency: renderproto-0.9.3
Dependency: recordproto-1.13.2
Dependency: randrproto-1.3.0
Dependency: printproto-1.0.4
Dependency: kbproto-1.0.3
Dependency: inputproto-1.5.0
Dependency: fixesproto-4.0
Dependency: dri2proto-2.0
Dependency: damageproto-1.1.0_2
Dependency: compositeproto-0.4
Dependency: font-util-1.0.1
Dependency: encodings-1.0.2,1
Dependency: expat-2.0.1
Dependency: gnome_subr-1.0
Dependency: dmidecode-2.10
Dependency: openldap-client-2.4.19
Dependency: pciids-20090807
Dependency: hicolor-icon-theme-0.10_2
Dependency: gnomehier-2.3_12
Dependency: python26-2.6.2_3
Dependency: xcb-proto-1.5
Dependency: svgalib-1.4.3_5
Dependency: png-1.2.40
Dependency: jpeg-7
Dependency: tiff-3.9.1_1
Dependency: pkg-config-0.23_1
Dependency: xproto-7.0.15
Dependency: pixman-0.16.0
Dependency: libtasn1-2.3
Dependency: libfontenc-1.0.4
Dependency: libXdmcp-1.0.2_1
Dependency: libXau-1.0.4
Dependency: libICE-1.0.4_1,1
Dependency: libSM-1.1.0_1,1
Dependency: freetype2-2.3.9_1
Dependency: mkfontscale-1.0.6
Dependency: mkfontdir-1.0.4
Dependency: fontconfig-2.6.0,1
Dependency: font-misc-meltho-1.0.0_1
Dependency: font-misc-ethiopic-1.0.0
Dependency: font-bh-ttf-1.0.0
Dependency: fftw3-3.2.2_1
Dependency: bitstream-vera-1.10_4
Dependency: xorg-fonts-truetype-7.4
Dependency: pcre-8.00
Dependency: libvolume_id-0.81.1
Dependency: libpthread-stubs-0.1
Dependency: libxcb-1.4
Dependency: libdrm-2.4.12
Dependency: libX11-1.2.1_1,1
Dependency: libXt-1.0.5_1
Dependency: libXrender-0.9.4_1
Dependency: libXft-2.1.13
Dependency: libXfixes-4.0.3_1
Dependency: libXext-1.0.5,1
Dependency: libXxf86vm-1.0.2
Dependency: libXxf86dga-1.0.2
Dependency: libXtst-1.0.3_1
Dependency: libXrandr-1.3.0
Dependency: libXpm-3.5.7
Dependency: libXp-1.0.0,1
Dependency: libXmu-1.0.4,1
Dependency: libXinerama-1.0.3,1
Dependency: libXi-1.2.1,1
Dependency: libXdamage-1.1.1
Dependency: libXcursor-1.1.9_1
Dependency: libXcomposite-0.4.0,1
Dependency: libXaw-1.0.5_1,1
Dependency: libGL-7.4.4
Dependency: libGLU-7.4.4
Dependency: libglut-7.4.4
Dependency: jasper-1.900.1_8
Dependency: glitz-0.5.6_2
Dependency: cairo-1.8.8,1
Dependency: aalib-1.4.r5_4
Dependency: libltdl-2.2.6a_1
Dependency: libgii-1.0.2_2
Dependency: libggi-2.2.2_3,1
Dependency: libexecinfo-1.1_3
Dependency: libdaemon-0.12
Dependency: icu-3.8.1_2
Dependency: glib-1.2.10_13
Dependency: gdbm-1.8.3_3
Dependency: perl-threaded-5.8.9_3
Dependency: libiconv-1.13.1
Dependency: libxml2-2.7.6
Dependency: gettext-0.17_1
Dependency: libgpg-error-1.7
Dependency: libgcrypt-1.4.4
Dependency: gtk-1.2.10_21
Dependency: glib-2.20.5
Dependency: gamin-0.1.10_3
Dependency: gio-fam-backend-2.20.5
Dependency: shared-mime-info-0.60_1
Dependency: pango-1.24.5
Dependency: libIDL-0.8.13
Dependency: dbus-1.2.4.6_1
Dependency: dbus-glib-0.82
Dependency: policykit-0.9_5
Dependency: consolekit-0.3.0_8
Dependency: hal-0.5.11_26
Dependency: avahi-app-0.6.25_2
Dependency: ORBit2-2.14.17
Dependency: portaudio-18.1_2
Dependency: nas-1.9.1_3
Dependency: libogg-1.1.4,4
Dependency: speex-1.2.r1_2,1
Dependency: libvorbis-1.2.3,3
Dependency: libaudiofile-0.2.6_1
Dependency: flac-1.2.1_1
Dependency: libsndfile-1.0.20_1
Dependency: libsamplerate-0.1.7_1
Dependency: esound-0.2.41
Dependency: libmikmod-esound-3.1.11_2
Dependency: celt-0.6.1
Dependency: jackit-0.116.2_2
Dependency: lzo2-2.03_2
Dependency: gnutls-2.8.3
Dependency: cups-client-1.3.10_4
Dependency: atk-1.26.0
Dependency: gtk-2.16.6
Dependency: gconf2-2.26.2_1
Dependency: pulseaudio-0.9.19
Dependency: sdl-1.2.13_4,2
Dependency: smpeg-0.4.4_8
Dependency: sdl_ttf-2.0.9
Dependency: sdl_mixer-1.2.8_2

discovery#

The list is long, but there is no qt. Now if one runs it under a WINDOW
MANAGER that uses on qt, then that WM might frame CF in a qt-decorated
window (i.e. its top bar, [X] button, etc), but that's not CF's dependency.

[Ernesto Domato]

Post by Ernesto Domato
Just to let you know, CF doesn't use QT, it uses SDL and for that
reason it's able to run in so many platform and architectures. So
please don't make any affirmation if you are not really sure about
what you're talking about.
Regards,
Ernesto.

Just as a fact check, here is the dependency list copied verbatim from my
freebsd system.
discovery# pkg_info -r crimson\*
Dependency: xineramaproto-1.1.2
Dependency: xf86vidmodeproto-2.2.2
Dependency: xf86dgaproto-2.0.3
[long freebsd dependeny list]
Dependency: gtk-2.16.6
Dependency: gconf2-2.26.2_1
Dependency: pulseaudio-0.9.19
Dependency: sdl-1.2.13_4,2
Dependency: smpeg-0.4.4_8
Dependency: sdl_ttf-2.0.9
Dependency: sdl_mixer-1.2.8_2
discovery#
The list is long, but there is no qt.  Now if one runs it under a WINDOW
MANAGER that uses on qt, then that WM might frame CF in a qt-decorated
window (i.e. its top bar, [X] button, etc), but that's not CF's dependency.

Please don't confuse system dependencies with software dependencies. I
don't use FreeBSD so I don't know what does "pkg_info -r" do, but it
has nothing to do with real dependencies for CF, it just seems to list
all the dependencies required to meet the needs for every other
package that CF needs but not necessary for just CF. What I mean is
that for example, on Debian GNU/Linux the dependencies listed for CF
are:

***@kcita:~/devel/debian$ apt-cache depends crimson
crimson
Depende: libc6
Depende: libgcc1
Depende: libsdl-mixer1.2
Depende: libsdl-ttf2.0-0
Depende: libsdl1.2debian
Depende: libstdc++6
Depende: zlib1g

A very short list in comparison with FreeBSD list. But, if you read
the installation document that comes with CF, at the beginning you
will find textually:

To compile or run Crimson Fields you need to have the following
dependencies installed:

SDL (>= 1.1.5, http://www.libsdl.org) and its companion libraries
SDL_ttf (http://www.libsdl.org/projects/SDL_ttf)
SDL_mixer (optional, http://www.libsdl.org/projects/SDL_mixer)
SDL_net (optional, >= 1.2.6 highly recommended,
http://www.libsdl.org/org/SDL_net)

Regards,
Ernesto.

[Константинов Юра]

So it's SDL_app-pkg, not KDE_app-pkg? Erm, making a SDL_app detect the sys-lng would be hard and should be done on a per-platform basis. As CF is now only 1 mb, will it ever be ported to SWF to play straight from the website?

[Nikola Smolenski]

Post by Jens Granseuer

Post by Nikola Smolenski
// Desktop environment detection done according to
// http://flyback.googlecode.com/svn/trunk/src/desktop.py
if(getenv("KDE_FULL_SESSION") || getenv("KDE_MULTIHEAD")) {

Eek! Now that's horrible! Even if we add per-platform code I certainly
don't want per-desktop code in there. I don't know how KDE does stuff,
but Gnome uses LANG and LC_* just like any other UNIX platform should.
That's basically the *only* approach I consider sane on UNIX systems.
Anything else will result in a horrible mess.

Gnome doesn't use LANG and LC_* variables. Gnome uses ~/.dmrc file while KDE
is supposed to but, at least in older versions, doesn't. I don't really see
how to do KDE language detection without doing KDE language detection, and
don't see why wouldn't it be done.

[Jens Granseuer]

Post by Nikola Smolenski
Gnome doesn't use LANG and LC_* variables. Gnome uses ~/.dmrc file while KDE
is supposed to but, at least in older versions, doesn't.

Yes, it does. It might use .dmrc to initialise the session, but all apps
honour the LC_* vars just fine.

Post by Nikola Smolenski
I don't really see
how to do KDE language detection without doing KDE language detection, and
don't see why wouldn't it be done.

The problem is there's about a gazillion different desktops out there,
and if each one does it differently we'll end up in a maze of twisty
little passages, all quite different, and none of them sufficiently
well-tested to actually work. Too many code paths (that you can't even
test properly at that) are hell. I don't want to go there.

Jens

[Nikola Smolenski]

Post by Jens Granseuer

Post by Nikola Smolenski
Gnome doesn't use LANG and LC_* variables. Gnome uses ~/.dmrc file while
KDE is supposed to but, at least in older versions, doesn't.

Yes, it does. It might use .dmrc to initialise the session, but all apps
honour the LC_* vars just fine.

Hmm. I could swear that it didn't work that way, but it does. Maybe it didn't
in earlier versions.

Post by Jens Granseuer

Post by Nikola Smolenski
I don't really see
how to do KDE language detection without doing KDE language detection,
and don't see why wouldn't it be done.

The problem is there's about a gazillion different desktops out there,
and if each one does it differently we'll end up in a maze of twisty
little passages, all quite different, and none of them sufficiently
well-tested to actually work. Too many code paths (that you can't even
test properly at that) are hell. I don't want to go there.

Justh KDE and Gnome together cover a large majority of users, and of the rest
some are standard-compliant. I wouldn't be so worried. Any way, it is strange
not to try to cover what is probably the most used CF environment.

[Nikola Smolenski]

Post by Ernesto Domato
I'll send the patches for the levels. The second patch is optional and
it implements the functionality that if you start the game for the
first time, so the configuration file doesn't exists yet, it display
the "Language Selection" windows so you can choose with language you
want to use. I did this because at least in my country is usual that

For another game I made (never implemented) a patch that reads the
system locale, perhaps that would be even better. I could adapt it for
CF if Jens approves.

[Jens Granseuer]

Post by Ernesto Domato
Well, here goes my first two patches for crimson field. The first one
implements the translations to Spanish of the engine and units, later
I'll send the patches for the levels.

Thanks, patch committed!

Jens

[Константинов Юра]