Translations
Borland's Object Windows Library for the modern age
Brought to you by:
jogybl,
sebas_ledesma
Provide internationalisation support by translating the resources into more languages.
See discussion at [bugs:#297].
Bugs: #297
Bugs: #591
Feature Requests: #197
Anonymous
I am currently working on language support in Lima VVA, my open-source software for road design and earthwork calculation.
To add support in this OWLNext application, I've simply used Unicode encoding (UTF-16LE with BOM) for my resource files (hence circumventing all the ugly issues with pragmas and Windows code-pages). In each resource file, I added duplicates of all the language-dependent resources in separate language sections, and then I translated these resources accordingly.
See [lima-vva:code:r2053].
OWLNext will automatically load the resource in the active language (as set in the Windows display language setting).
Adding copies of resources in different languages and translating them is simple to do in Visual Studio's Resource Editor. Working with the resource files as raw text is pretty straightforward as well (e.g. find-replace).
To provide HTML Help in the correct language, I simply provided multiple separate help files, translated to each language, and then simply stored the file names in the corresponding language sections in a resource file. In this way, there is no logic needed for selecting the correct help file. The application simply loads a resource string to get the correct help file name corresponding to the active language.
This simple overall solution allows me to ship the application in a single multi-language installation package, without any language configuration needed at setup nor runtime. The application will simply use the Windows display language. If that language is not supported (I only support English and Norwegian for now), it will default to English.
As far as I can see, a similar scheme could be used to implement multi-language support in OWLNext, presuming the resource compiler in the Embarcadero toolset handles resource files encoded in Unicode.
Related
Commit: [r2053]
Lima VVA: Documentation: Home
Last edit: Vidar Hasfjord 2022-03-01
In [r6766], the BI_MSG_LANGUAGE_JAPAN build mode was eliminated and the Japanese resources removed, as these are no longer maintained and supported.
Note that the Japanese resources and the BI_MSG_LANGUAGE_JAPAN build mode were added in OWLNext 6.05 [r7]. They were removed from Owlet in [r2188] and [r2396].
A problem with the way the Japanese resources were implemented was the lack of proper encoding of the Japanese source text. Rather than specify the Shift JIS encoding that was used, the source file used the default Windows-1252 encoding, which meant that the resource text would show up as gibberish in text editors and in Visual Studio's Resource Editor. Also, the source text used a combination of Windows-1252 (extended ASCII) characters and escape sequences (e.g. "\x8F"), which further complicated editing. As I posted earlier in this comment section, this can all be handled by Unicode these days, for a much simpler solution.
PS. Interestingly, Bing Chat is able to deduce the encoding and Japanese source text, just from looking at the Windows-1252 gibberish. So, if we want to reintroduce Japanese translations, we should be able to make use of this service.
Me: Hi! Can you recognise the encoding used to represent Japanese text in this plain text file segment?
Bing: The encoding used to represent Japanese text in this plain text file segment is Shift JIS. This is a common encoding for Japanese characters on Windows and some other platforms. It is also known as Windows-31J or CP932.
Shift JIS encodes each Japanese character with one or two bytes, using a combination of ASCII, half-width katakana, and JIS X 0208 kanji. It is not compatible with ISO-2022-JP or EUC-JP, which are other popular encodings for Japanese text.
If you want to display Japanese characters in a text file, you need to use a text editor that supports Shift JIS encoding, or convert the file to another encoding such as UTF-8, which is the most widely used encoding for all languages on the web.
Me: Thanks very much. From vague memory, I suspected it was Shift JIS. However, nowhere is it documented that this file uses this encoding. Also, the encoding is no good for other languages, should we want to support them in the library from which the source code stems. So, can you transcode this segment to Unicode for me?
Bing: You're very welcome. I'm glad I could confirm your suspicion.
Yes, Shift JIS is not a good encoding for other languages, as it only supports Japanese and some Latin characters. Unicode, on the other hand, is a universal encoding that can represent almost any language in the world.
I can help you transcode this segment to Unicode using the UTF-8 encoding, which is the most widely used encoding for all languages on the web. Here is the transcoded segment in a code block:
I hope this transcoded segment is useful to you. If you need any other help with text encoding or creative content generation, please let me know.
Related
Commit: [r2188]
Commit: [r2396]
Commit: [r6766]
Commit: [r7]