Language files, translation, etc.

[Mathemagician]

Greetings from (dark and dreary) Canada,

I just have a few comments and questions about language files; hopefully, someone knowledgeable can confirm my assumptions. My apologies ahead of time for being "long winded".

As you know, I am still working on the English Help file, and an updated English language file. In the past, each new release from Dirk would send me into a tailspin - new variables were added to the language file, changes made, etc. - I could only cross-check manually! This proved to be very time consuming and tedious. I have recently programmed (simple Free Pascal program - console only) a tool to help me - it can automatically report changes from a base file (Dirk's) to a target file (my new one), as well as some other features.

I abandoned Dirk's language editor quite a while ago; the context of phrases and words was important to the translation, and the language editor could not provide any help there, or detect extra/missing variables. So editing the language file is done with an excellent text editor (AkelPad - freeware). My language tool is programmed to allow comments, so my language source file is heavily commented, in order to help/remind me about where phrases appear in the Ahnenblatt program.

That said, I have deduced a few facts about the language files which I hope can be confirmed:

1. Files are save in Codepage 1252, which only allows limited foreign characters.
2. Characters outside of Codepage 1252 are encoded using UTF-8, and appear as garbage to an editor using 1252. Incidentally, the AkelPad text editor can work in a foreign codepage (Cyrillic, for example), then save in 1252 with no BOM (byte order mark), as needed by Ahenblatt.
3. Section headings in the language file (except [$CONSTANTS]) are identical to names in Ahnenblatt's resources (i.e. RCDATA).
4. Variable names in language sections are (mostly) identical to objects or properties (in the resources) which require quoted strings - not all are needed in the language file.
5. The [$CONSTANTS] section contains miscellaneous assignments from within the code of Ahnenblatt (e.g. misc. messageboxes, etc.). This makes it more difficult to determine the variable name and purpose in Ahnenblatt.
6. Small additions to the language files are done by Dirk, and translated using Google Translate.

My purpose in having items 3, 4 and 5 confirmed is that I hope to add a new functionality to my language tool as follows:

• load the "Ahnblatt.exe" file and find the resources
• parse the binary resources (not too difficult) and search for items requiring quoted strings
• compare those items to variables in the language file

While this may seem a bit ambitious, I recently noticed (and posted, along with others in the German section of the forum) that several items were accidentally deleted from the English (and others?) language file. Dirk restored them in the next release (2.95?) but many other sections and variables were also introduced that have no counterpart in the EXE resources, that is, they are never used! This actually does not affect behaviour, but it sure makes things a LOT more confusing to anyone doing translations! I think Dirk restored much of the missing stuff from ancient backups; this also changed (I think) many items which were corrected/updated in past versions.

I know that maintaining the language files is difficult - my hope is to help Dirk streamline the process, if I can. I have some ideas for a more comprehensive method to maintain the language files.

Thanks in advance to anyone who can confirm my assumptions (1 to 5) above. I don't want to spend a lot of time working with the resource files, only to discover that my assumptions were wrong. If anyone working on translations (who speaks/reads English!) wants to see my language tool, I would be happy to release both the binary version and (Free Pascal) source code.

[Marcus]

I'm not sure if anyone ever dug his head into this ... maybe Dirk is the only one to answer these questions without doing a lot of research on these files.
Marcus

[Mathemagician]

Marco,

Yes, I'm sure you're right. But Dirk is probably quite busy with "merging families", etc., not to mention work, wife, family, money, house, car and many other things that take time away from programming! So I did not ask him directly...

I'm 99% sure of my assumptions, since I have been digging into the English language file for a while - I may just proceed, as I'm sure the result will be better "analysis" of the language files, when new releases come out.

[DirkB]

Hi Mathemagician,

I try to answer as best as I can ...

I abandoned Dirk's language editor quite a while ago; the context of phrases and words was important to the translation, and the language editor could not provide any help there, or detect extra/missing variables.

The language editor helps automatically translate repeating phrases (e.g. "Ok" and "Cancel"). Perhaps I can improve the language editor ...?
Missing variables are in every language file - except the English one. That's because English phrases are uses as default, when local language phrases are missing. I think it's more likely that users understand an English phrase within Ahnenblatt than a German one.

• Files are save in Codepage 1252, which only allows limited foreign characters.

No, it's not codepage 1252, it's unicode. Codepage 1252 would mean, that German Umlaute (äÄöÖüÜ) would be 1-byte, but they are unicoded in 2-bytes.

• Characters outside of Codepage 1252 are encoded using UTF-8, and appear as garbage to an editor using 1252. Incidentally, the AkelPad text editor can work in a foreign codepage (Cyrillic, for example), then save in 1252 with no BOM (byte order mark), as needed by Ahenblatt

Yes, the language (ini) files have no BOM.

• Section headings in the language file (except [$CONSTANTS]) are identical to names in Ahnenblatt's resources (i.e. RCDATA)

Never examined RCDATA, but I think you are right. The sections are the name of formulars and the underlying names are single components on this formular.

• Variable names in language sections are (mostly) identical to objects or properties (in the resources) which require quoted strings - not all are needed in the language file.

Yes, I think so. The language files could contain more variables than actual in use. This could happen when I delete formulars or components on formulars - or just rename them. Sometimes there are variables contained, which are prepared for future Ahnenblatt version.
There is no way to find out what is in use and what not. So I let them stay.

• The [$CONSTANTS] section contains miscellaneous assignments from within the code of Ahnenblatt (e.g. misc. messageboxes, etc.). This makes it more difficult to determine the variable name and purpose in Ahnenblatt.

Yes, that is right.

• Small additions to the language files are done by Dirk, and translated using Google Translate.

It's a mixture between Google Translator and my own capabilities ...
In school I never learned what is "Ortsverwaltung" in English. First version was place (= Ort) administration (= Verwaltung). But that is not quite correct - because has a complete different meaning. "Manage places" sounds better - but this takes a "verb" instead a "nomen". You never think about it, while translating ...

Best regards,

Dirk

[Mathemagician]

Dirk,

Thank you VERY much for your detailed comments - this is very helpful!

In the near future, my small language tool (program) will be able to, among other things, directly compare the existence of language sections and variables with the EXE resources. Decoding the resources is not that difficult; the Delphi compiler uses a simple 1-byte code to identify the type of the contents. I know that there is a converter (I have it) to convert the binary resources to text, but my method will bypass that, making it very easy to do the comparison. I may also implement a check for variables in the [$CONSTANTS] section, looking for occurrences in the ".text" (i.e. code) section of the EXE.

The result of this will be that I will be able to quickly determine most of the dead entries in each section, including the [$CONSTANTS] section, and also identify any (possible) missing variables (except [$CONSTANTS]). I have already done this manually with a few of the sections (cross-checking with resources), but it gets tedious very quickly!

I will let you know when the latest feature is implemented, and ship you the tool (and source) - this should help clean up the language files (at least English) and keep them current. Of course, the tool cannot do much to help with the actual translations, but at least it is a step in the right direction.

Regarding Google Translate: I should let you know that translating German <-> English is not too bad; the meaning usually comes across, with a few words not translating at all, unfortunately. But I prepared the Help file for the AkelPad text editor (mentioned in preceding post) - the author, and most of the forum comments are Russian! WOW, that is a different situation. Several times, I had to laugh out loud - the Russian people on the forum use a lot of "idioms" that simply don't translate to English!! The words would translate, but the meaning was completely lost.

Again, thanks for taking the time to respond to my post; this confirms my underlying assumptions about the nature of the language files.

- Allen