Hi,

I'm stuck with some sort of nasty problem:

While doing internationalization in a program planned only for german users I started to use the gettext mechanism to translate any descriptive GUI string. The mean part is that my original strings (now used as resourcestrings) do not work if they have german umlauts or the like in it. I want to avoid having to put anything to us-ascii first to get it done.

From looking at the sources of gettext.pp i know the comparison is done

with "StrComp", but this is where I'm stuck. If i use e.g. 'ü' it is represented as \374 (it is $FC) as in:

#: state1:srdataswap
msgid " - Daten\374bertragung"
msgstr "anything, testing only"

in the .po file. But in translation the msgid is not found (testing with fr_FR as $LANG), but this here:

#: conststr:srokay
msgid "OK"
msgstr "Oui"

does work. In the .mo file the hex value is $FC as expected (in a hex viewer with french LANG var).

Can someone explain to me what's wrong here and maybe how to get around it?

TIA,
Marc

Hallo Marc,

I reported this a long time ago, and got an answer like: gettext doesn't accept source strings in UTF-8.
The easiest way to solve it is to write the program in English (with english on buttons, etc) and then write a po file for german. I know, I know, not elegant or easy, but it works. Note that the strings must be edited with a UTF-8 editor.

John

Hallo Marc,

Hi John,

I reported this a long time ago, and got an answer like: gettext doesn't accept source strings in UTF-8.

Ah, I see. This inspired me to do some further tests and I found a solution that is more acceptable than doing what I don't want to do.

I found from some quick tests that it is rstconv that cannot handle the encoded strings. Replacing them in the generated .po file seems to do the trick.

Needs more testing but might be okay when done by some shellscript ... :)

The easiest way to solve it is to write the program in English (with english on buttons, etc) and then write a po file for german. I know, I know, not elegant or easy, but it works. Note that the strings must be edited with a UTF-8 editor.

Yes, as a last solution I'd have to do it that way.

Thank you very much,
Marc

You might look at the GNUGetText for Delphi - they have solved the problem of non-english source identifiers.
Matthias.

Trying again, third time the server was blacklisted ...

Hi Matthias,

You might look at the GNUGetText for Delphi - they have solved the problem of non-english source identifiers.

Thanks for your hint.

Do you use that one with fpc? The source looks rather Delphi/Kylix'ish.

TIA,
Marc

More testing shows it does work with single char strings and does not with real strings.

I still do not understand this, does someone know, why "StrComp" behaves this way?

Marc

Do you use that one with fpc? The source looks rather Delphi/Kylix'ish.

Nope, but I guess you can find there the solution for it. Just get the GNUGetText.pas and look for changes made in version 1.2. Since this version GNUGetText supports UTF8 strings in strids.

On the other hand I missed the possibility to "compile" a .po file in my application instead of loading a ready-made .mo file. So I started my own implementation (based on GNUGetText.pas, gettext.pp and the original implementation of GNU GetText). It will support the following features:

- strids don't have to be "pure english" anymore
- compile under delphi/fpc (win32 target strongly tested)
- plural forms

If you're interested I can give you some draft implementations that I've made.

Regards
Matthias.

Ah, fine. I'll do that first.

Do I understand correctly that your implementation goal is to handle the creation of .mo files programmatically?

This sounds interesting, but I'm under pressure of my deadline and the decision if I have to swap the base language or find an acceptable quick way of using german language as basis.

Anything that can help me in reaching this goal is very much appreciated and will give me more time for other tasks. ;)

Gruß,
Marc