#297 RC crashes when attempting Japanese builds

[Joe Slater]

With regards to Japanese builds:

The file winsock.rc has extraneous commas after the strings in the stringtable which causes RC.EXE to crash. There are also a couple of RC files containing a backslash not escaped. There are several RC files containing non-displayable characters in the multi-byte strings, posing hazard when editing in common text editors. These characters should be escaped with the equivalent hex code.

[Joe Slater]

Sorry for all the changes… [r2936], [r2937], [r2938], [r2939]. Had a bit of trouble with VS2013 RC. It should be okay now.

[Joe Slater]

I do not see a Blame command in my TurtleSVN :-)

Since you just had a maintenance release, I wouldn't worry about it. These RC files are not part of the lib/dll builds; user applications would include them with their apps along with the appropriate define for including Japanese resources. Presumably, Windows would load those strings if the locale was set for Japanese. And nobody has complained about it. It doesn't affect OWLNext builds, so it's not crucial; but it does attempt to satisfy the pedantics. :-)

[Vidar Hasfjord]

Hi Joe,

How far back does this issue go?

By the way, on the Owlet branch the translations have already been removed, I think.

Note that OWLMaker has no build option for translated versions of the libraries, and we have no naming convention for translated library files. This is needed to do translation properly, unless, we chose to make the current conditional code unconditional and thus include all translations in one.

Now that the job is done, and you want to maintain it going forward (I presume), maybe we should update the RC file to Unicode encoding so that the characters appear correctly and can be edited in any Unicode viewer/editor? That will allow us to simply add translations for other languages as well, without having to mess with old-style code pages.

I think resources are stored in the target binary as Unicode anyway.

I do not see a Blame command in my TurtleSVN :-)

It is only available on individual files: Open the context menu for "include/owl/winsock.rc", select "TortoiseSVN | Blame". This will open the TortoiseBlame viewer which shows, in the left margin, the revision number for each line, for which that line was revised. By the way, it appears that the Japanese string table in this file was added in [r7] (OWLNext 6.08) and has not changed since. So this feature has been broken since then, at least.

These RC files are not part of the lib/dll builds

The resources are part of the DLL, but not the LIB, as you rightly say. But, since adding more translated resources to a DLL does not change the ABI interface of the library, there is no pressing need for a naming convention, contrary to what I stated earlier.

And nobody has complained about [the Japanese translation option].

Probably because it was well hidden (no option in OWLMaker to use it), and because it never built in the first place for those who found it and tried it. Until you did. :-)

[Joe Slater]

Hi Vidar,

Firstly, unrelated except in the sense of RC files, I noticed that all.rc doesn't actually include them all; there are two that are not. One of them is a depreciated file, which is okay. The other is urllink.rc — I don't know whether it should, but in case it did I thought I'd mention it.

TortoiseSVN | Blame
 

Found it. Tried it. And I concur it was added in [r7]. But I'm not sure it has really been broken since then… A thought led me to try the old Borland v5.5 to see if it had issues with the syntax of a trailing comma — it did not, and compiled it just fine.

I think resources are stored in the target binary as Unicode anyway
 

That is correct; binary resources are Unicode, regardless if the application is.

resources are part of the DLL… no pressing need for a naming convention
 

Okay, in light of such, it's probably likely the DLLs do not have the Japanese strings. Only if the symbol BI_MSG_LANGUAGE_JAPAN is defined at compile time do these strings get included. I am pretty sure I noticed a discrepancy, in that sometimes in an RC file if Japanese is included, sometimes the English version still is and other times not. This is probably due to a migration step in adding language ids to the RC files. Another consideration is the size of the EXE file will grow with all languages embedded (another “old days” concern).

update the RC file to Unicode encoding
 

I don't think we should do anything until we rethink all of this (there seems to be no pressing need). At the present, Japanese I believe is the only other language supported, and only in part probably. I don't even know Japanese, and got involved in this with fixing/changing validator stuff. My own pedantic nature despises partial implementations, so adding new messages required that the Japanese equivalent was added (which has led me to learning about multi-byte and writing my first Unicode application).

And I have no idea as to whether or not my new Japanese messages are even “correct.” I am familiar with a little bit of Spanish, and the literal translation of “What is your name” in Spanish is “Que es su nombre” - but that's not a proper Spanish translation in usage. They say “Como se llama” which translates to “How are you called.” But at least my implementations included Japanese, and if it's not the proper phrase I figure someone can issue a ticket on it.

I believe many modern-day multi-lingual implementations use separate resource files (DLLs?) representing different languages. The user picks a language (often at installation time) and the appropriate resource file is used thereafter. This seems to be a logical approach.

Meanwhile, I believe it all hinges on whether the direction of OWLNext is going to provide internationalization, and if there's qualified volunteers to perform the necessities. We can't even really say we support English… It's more like US-English, as British English and Norwegian pluralized English isn't supported. :-)

P.S. As an aside, using the VS2013 template provided, I had trouble building my app as a Unicode application… Net research indicated a fix such that I needed to add /ENTRY:"wWinMainCRTStartup" in the project | configuration properties | linker | command line. That fixed it, but I was wondering whether there was a better way to do this, such that if I toggle Unicode on/off, I do not have to add/remove the aforementioned.

[Joe Slater]

Another Japanese-related concern crept up during my examination of the TPXPictureValidator code. Another define symbol is used for Japanese, and it bypasses loading a resource string. Here's a code snippet:

#if defined(BI_PDOXWINJ_SUPPORT)
  // Paradox for Windows/J database program has two special picture to
  // support Japanese characters in CodePage 932
  //
  // '“' 0x81+0x93 - (2 byte '%' symbol)
  //      1 byte KATAKANA and KATAKANA symbols (0xA1 - 0xDF)
  // '—' 0x81+0x97 - (2 byte '@' symbol)
  //      any 2 byte characters except 2 byte space (0x81+0x40)
  //
  // This is hard coded, because we don't know how to get current
  // code page in Windows 3.1
  // …
#endif

Clearly Japanese is not properly supported with the supplied builds.

Windows 3.1? I remember that! :-)

[Vidar Hasfjord]

I noticed that all.rc doesn't actually include them all; there are two that are not. One of them is a depreciated file, which is okay. The other is urllink.rc

On the trunk, TUrlLink has been moved to OWLExt, so "urlink.rc" was removed from "all.rc".

In 6.40, "urllink.rc" is present in "all.rc" (branches/640/include/owl/all.rc), so I do not see anything wrong.

What was the other file?

PS. We should probably start using the Developer forum for unrelated discussion, to keep tickets simple for review.

[Vidar Hasfjord]

I had trouble building my app as a Unicode application… Net research indicated a fix such that I needed to add /ENTRY:"wWinMainCRTStartup"

That is a FAQ.

I have now updated the article describing the template to include this information.

[Joe Slater]

using the Developer forum… keep tickets simple for review.
 

Okay, I'll wrap it up with this post.

TUrlLink has been moved to OWLExt, so "urlink.rc" was removed from "all.rc"
 

Never mind.

What was the other file?
 

"listview.rc" which has been superseded by "listboxview.rc" and doesn't need to be included. All is well.

binary resources are Unicode
 

That's not exactly true; they are wide-char format. Issuing a LoadString whether a Unicode application or not, will return back a string appearing the same as what is stored in the RC file.

update the RC file to Unicode encoding
 

In light of the above, that would be a major breaking change for existing (legacy?) Japanese applications, since the resource has MB (stored in WC) instead of Unicode. I presume such applications, if Unicode, convert the LoadString to SB and then call MultiByteToWideChar (code page 932) to get the Japanese Unicode (it's what I did to see it properly).

[Vidar Hasfjord]

Okay, I'll wrap it up with this post.

Anything translation-related can continue here, of course. But, even better yet, open a new general topic on translation in the Open forum — maybe it will catch interest. Any internal discussion, i.e. of little interest to the wider community, about issues unrelated to the ticket is best discussed in the Developer forum.

Issuing a LoadString whether a Unicode application or not, will return back a string appearing the same as what is stored in the RC file.

That makes sense. If we use Unicode encoding, we must ensure everything is encoded accordingly in the sources. E.g. we must used prefixed wide strings in the RC source (e.g. L"japanese"). But, assuming the source and the resulting binary resources contain correctly encoded Unicode text (UTF-16), my understanding is that LoadStringA will do the conversion to narrow string using the code page of the current locale.

If it should not be as simple as this, we can state that the translations are only available if building the application in Unicode mode. I think any investment of time and resources in old code pages (SBCS/MBCS) is misguided.

See the Unires example from Microsoft.

[Joe Slater]

Saving the RC file as a Unicode file doesn't solve any problems. Typing in the Unicode Japanese characters directly breaks everything, as current apps using Japanese expect MB strings in the resource file.

LoadStringA will do the conversion to narrow string using the code page of the current locale.
 

ANSI as Unicode is simply ANSI with a 0 high-order byte added, and LoadStringA will simply strip off the high-order byte back to SB ANSI. MB is a logical representation, and I do not believe that LoadStringA knows anything about that (that's what MultiByteToWideChar and WideCharToMultiByte are for). It just attempts to convert it to SB.

If true Japanese Unicode (not as MB) was stored in the resource, LoadStringA will fail miserably because those characters cannot be represented in SB format no matter the code page except through the use of MB representation, which not only needs a code page, but other conversion settings too — see WideCharToMultiByte).

[Vidar Hasfjord]

Hi Joe,

Saving the RC file as a Unicode file doesn't solve any problems.

Unicode should solve all problems with encoding, so I doubt your analysis. But should you be right, please point to documentation.

MSDN | Windows Resource Files | Compiling Resources says: "All Win32 resource strings are compiled into Unicode format, but the .RC file format is still expressed in the current default Windows character set."

LoadStringA will simply strip off the high-order byte back to SB ANSI.

I assume this is just a symptom of the incorrect code page (probably ASCII) being used by the resource compiler in the first place. The compiler needs to know the encoding of the file to convert text literals to Unicode correctly. But, currently we do not set the code page in the resource files, so the default (local) code page will be used.

The pragma "code_page" specifies the encoding of a resource file:

#include "English.rc"
#pragma code_page(932)
#include "Japanese.rc"

See Resource Compiler | About Resource Files | Pragma Directives.

But the better option is to store the RC file as Unicode UTF-16 with a BOM. The resource compiler should then recognise that the file is encoded as Unicode, and the file will display correctly in any Unicode enabled editor. But, note, we then need to actually change the strings to correctly encoded and prefixed Unicode literals in the resource script itself (e.g. L"Japanese"). Narrow strings will be assumed to belong to the ASCII subset of Unicode.

If true Japanese Unicode (not as MB) was stored in the resource, LoadStringA will fail miserably

I doubt this, and would find it unexpected, considering that the rest of the Windows API converts between Unicode wide text and ANSI narrow text (current code page, SBCS/MBCS) in every other A/W pair of functions. (As I understand it, Windows operates internally solely on Unicode, so all ANSI text functions simply do a conversion and use the corresponding Unicode variants of the functions.)

However, even if you should be right, we should still use Unicode in the resource files, and wrap LoadString in a conversion function. In my view, Unicode is the only sensible option for dealing with character sets in this day and age. Merely loading raw MBCS Japanese into the application, whose active code page may not even match, is not a good option.

[Joe Slater]

Firstly, I just don't know if anyone is using the Japanese features that have been implemented in OWL at present. So if any changes are a breaking change, I just don't know.

Secondly, historically I don't know how the Japanese was used. Was it pre-Unicode days? Conceivably, a font could've been installed that interpreted MB and would draw the Japanese glyph characters correctly. I just don't know. I do know that Windows did (does?) have specially generated versions for use in Asian countries.

Thirdly, the old Borland/OWL had this implemented (slightly modified here for presentation) at compile time:

int LoadStringA(HINSTANCE hInstance, UINT uID, LPSTR lpBuffer, int nBufferMax);
int LoadStringW(HINSTANCE hInstance, UINT uID, LPWSTR lpBuffer, int nBufferMax);
#ifdef UNICODE
#define LoadString LoadStringW
#else
#define LoadString LoadStringA
#endif // !UNICODE

It doesn't appear to work that way anymore in OWL. LoadStringA and LoadStringW still exist in Windows, but I've had difficulty finding useful information about them. I haven't seen any "official" documentation with details how LoadStringA works.

With respect to the way the OWL RC files currently exist, the strings are ANSI (i.e., SB). They are merely converted to wide-char ANSI in the binary RES file (i.e., high-order 0 byte). There is no magical transformation to true Japanese Unicode by the RC compiler. The LANG statement in the RC file merely specifies which string table to load for an app based on the locale set in the app (I have verified this).

The information of the #pragma code_page(932) you gave also did not specify whether MB would be transformed to true Japanese Unicode, but in my test it did not.

Now, let's say the RC files are edited to be true Unicode, with Japanese text (i.e., no more MB).

Does LoadStringA convert it to MB? I just don't know. Does it matter? Probably not, but somewhat depends on questions posed at the start of this post.

In any case, it doesn't matter with respect to OWLNext; it doesn't seem to call it explicitly anymore (see module.cpp). Instead, it does make the conversions by explicitly calling WideCharToMultiByte. That's good, but the downside is that conversion flags cannot be specified by the app when that takes place. That would also be true even if the WINAPI LoadStringA does an implicit conversion.

So, if the RC files are set to true Unicode, and these supposed Japanese apps are not Unicode (which seems rather unlikely, but depends on the unanswered questions initially posed), then it should be a non-breaking change since OWLNext would convert them to MB as the app expects.

But, if these Japanese apps are Unicode, it would be a breaking change as it would no longer receive MB but true Japanese Unicode. That would make it easier on the app, but it would be a change. In my test Unicode program with the RC files as-is, I have to take the LoadString result, convert it to SB by calling WideCharToMultiByte even though "logically" it already is MB (it simply strips off the high-order 0 byte), then call MultiByteToWideChar using the Japanese code page to get true Japanese Unicode (I have verified this).

The bottom line after this lengthy prose, is that I do believe it is a worthwhile change to change the RC files to true Unicode, but it needs to be made clear to any existing Unicode Japanese apps that it is a breaking change; the aforementioned procedure of calling WideCharToMultiByte followed by MultiByteToWideChar would no longer be needed.

[Vidar Hasfjord]

Hi Joe,

I'm not too concerned about backwards compatibility here. I doubt the feature is being used. But I continue the discussion with future support for translations in mind.

[about adopting Unicode being a breaking change]

It shouldn't be, as far as I can see. Consider how the Japanese feature may have been used correctly so far: The Japanese developer enables BI_MSG_LANGUAGE_JAPAN and compiles OWLNext on a system whose local locale is set to Japan with a corresponding Japanese code page. Without any "code_page" pragma in the resource files, the resource compiler assumes the local code page (Japanese) and converts strings accordingly. The resulting binary resource files end up with the Japanese strings as properly encoded Unicode.

That is my understanding.

With respect to the way the OWL RC files currently exist, the strings are ANSI (i.e., SB).

Strictly speaking the encoding of the resource files is currently unspecified, i.e. the compiler will use the default locale, assuming the local locale on the developer's system (I presume).

[The Japanese strings] are merely converted to wide-char ANSI in the binary RES file (i.e., high-order 0 byte).

Simpler put: It is incorrectly encoded text, i.e. a bug resulting from using the incorrect code page. The result is gibberish. So, we should not have to consider handling this case.

pragma code_page(932) [did not work]

Strange. Did you misspell it?

There is no magical transformation to true Japanese Unicode by the RC compiler.

There should be. If the resource compiler is informed about the correct code page, the conversion to Unicode should happen correctly, and the resulting binary resources should contain Japanese text encoded as UTF-16.

PS. Regarding your LoadString comments, the macro convention used to substitute A/W functions, depending on the Unicode build mode, is used all over the Windows API, so I see nothing special about LoadString.

[Joe Slater]

Hi Vidar,

In my test Unicode application, I have in the RC file the following, without a define for BI_MSG_LANGUAGE_JAPAN:

#include <owl/validate.rc>
#include "japan.rc"

The contents of japan.rc are:

#pragma code_page(932)

LANGUAGE LANG_JAPANESE, SUBLANG_NEUTRAL

STRINGTABLE
{
  IDS_VALPXPCONFORM, "“ü—ÍÃÞ°À‚Í\x8F‘\x8E®‚É“K\x8D‡‚µ‚Ü‚¹‚ñ\x81" "B\n""%s"""
  IDS_VALINVALIDCHAR, "“ü—ÍÃÞ°À’†‚É•s\x90³‚È•¶\x8Eš‚ª‚ ‚è‚Ü‚·\x81" "B"
  IDS_VALNOTINRANGE, "“ü—Í‚³‚ꂽ’l‚Í %ld ‚©‚ç %ld ‚͈͓̔à‚Å‚Í‚ ‚è‚Ü‚¹‚ñ\x81" "B"
  IDS_VALNOTINLIST, "“ü—Í‚³‚ꂽÃÞ°À‚Í—LŒø‚ÈؽĒ†‚Ì‚à‚Ì‚Å‚Í‚ ‚è‚Ü‚¹‚ñ\x81" "B"
  IDS_VALREQUIRED, "“ü—Í‚ª•K—v‚Å‚·"
  IDS_VALNONBLANK, "”ñƒuƒ‰ƒ“ƒN‚Ì“ü—Í‚ª•K—v‚Å‚·"
  IDS_VALCAPTION, "–³Œø“ü—Í"
}

A hex dump of the RES file of japan.rc has:

00000000: .... ...ÿÿ..ÿÿ.. 00 00 00 00 20 00 00 00 FF FF 00 00 FF FF 00 00
00000010: ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000020: Ô... ...ÿÿ..ÿÿñ. D4 01 00 00 20 00 00 00 FF FF 06 00 FF FF F1 07
00000030: ....0........... 00 00 00 00 30 10 11 00 00 00 00 00 00 00 00 00
00000040: ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000050: #.. ü.. Í.Ã.Þ.°. 23 00 1C 20 FC 00 14 20 CD 00 C3 00 DE 00 B0 00
00000060: À.. Í.û0. û0®..  C0 00 1A 20 CD 00 FB 30 18 20 FB 30 AE 00 1A 20
00000070: É.. K.û0! . µ..  C9 00 1C 20 4B 00 FB 30 21 20 1A 20 B5 00 1A 20
00000080: Ü.. ¹.. ñ.û0B... DC 00 1A 20 B9 00 1A 20 F1 00 FB 30 42 00 0A 00
00000090: ".%.s.".".. ü..  22 00 25 00 73 00 22 00 22 00 1C 20 FC 00 14 20
000000A0: Í.Ã.Þ.°.À..   .  CD 00 C3 00 DE 00 B0 00 C0 00 19 20 20 20 1A 20
000000B0: É." s.û0³.. È."  C9 00 22 20 73 00 FB 30 B3 00 1A 20 C8 00 22 20
000000C0: ¶.û0a.. ª..  ..  B6 00 FB 30 61 01 1A 20 AA 00 1A 20 A0 00 1A 20
000000D0: è.. Ü.. ·.û0B.4. E8 00 1A 20 DC 00 1A 20 B7 00 FB 30 42 00 34 00
000000E0: . ü.. Í.. ³.. ê. 1C 20 FC 00 14 20 CD 00 1A 20 B3 00 1A 20 EA 00
000000F0: . ½.. l.. Í. .%. 1A 20 BD 00 19 20 6C 00 1A 20 CD 00 20 00 25 00
00000100: l.d. .. ©.. ç. . 6C 00 64 00 20 00 1A 20 A9 00 1A 20 E7 00 20 00
00000110: %.l.d. .. Ì.. Í. 25 00 6C 00 64 00 20 00 1A 20 CC 00 1D 20 CD 00
00000120: Æ.Í.. à.. Å.. Í. C6 02 CD 00 1C 20 E0 00 1A 20 C5 00 1A 20 CD 00
00000130: .  .. è.. Ü.. ¹. 1A 20 A0 00 1A 20 E8 00 1A 20 DC 00 1A 20 B9 00
00000140: . ñ.û0B.1.. ü..  1A 20 F1 00 FB 30 42 00 31 00 1C 20 FC 00 14 20
00000150: Í.. ³.. ê.. ½.Ã. CD 00 1A 20 B3 00 1A 20 EA 00 1A 20 BD 00 C3 00
00000160: Þ.°.À.. Í.. L.R. DE 00 B0 00 C0 00 1A 20 CD 00 14 20 4C 00 52 01
00000170: ø.. È.Ø.½.Ä..    F8 00 1A 20 C8 00 D8 00 BD 00 C4 00 19 20 20 20
00000180: . Ì.. à.. Ì.. Å. 1A 20 CC 00 1A 20 E0 00 1A 20 CC 00 1A 20 C5 00
00000190: . Í..  .. è.. Ü. 1A 20 CD 00 1A 20 A0 00 1A 20 E8 00 1A 20 DC 00
000001A0: . ¹.. ñ.û0B....  1A 20 B9 00 1A 20 F1 00 FB 30 42 00 0E 00 1C 20
000001B0: ü.. Í.. ª." K..  FC 00 14 20 CD 00 1A 20 AA 00 22 20 4B 00 14 20
000001C0: v.. Å.. ·.... ñ. 76 00 1A 20 C5 00 1A 20 B7 00 1A 00 1D 20 F1 00
000001D0: ’.u.’.0 ’.. ’.N. 92 01 75 00 92 01 30 20 92 01 1C 20 92 01 4E 00
000001E0: . Ì.. ü.. Í.. ª. 1A 20 CC 00 1C 20 FC 00 14 20 CD 00 1A 20 AA 00
000001F0: " K.. v.. Å.. ·. 22 20 4B 00 14 20 76 00 1A 20 C5 00 1A 20 B7 00
00000200: ... ³.R.ø.. ü..  08 00 13 20 B3 00 52 01 F8 00 1C 20 FC 00 14 20
00000210: Í...             CD 00 00 00

There is no Japanese Unicode text there.

So as expected in my test application the following:

// String stream we'll use for message
tostringstream sMsg;

// Save current language and set it to Japanese
TLangId curLang = GetLangId();
SetLangId(MAKELANGID(LANG_JAPANESE, SUBLANG_NEUTRAL));

// Get the Japanese version of the string
tstring s = LoadString(IDS_VALNONBLANK);

// Restore original language and get its version of the string
SetLangId(curLang);
sMsg << _T("LoadString() Default:\t\t[") << LoadString(IDS_VALNONBLANK) << _T("]\n");
sMsg << _T("LoadString() Japanese:\t[") << s << _T("]\n");

// Display results to user
MessageBox(sMsg.str().c_str(), _T("Validator Japanese Message Test"));

shows what I have in a screen snapshot image attached.

In this case, TModule::LoadString does no conversion because it's wide-char to wide-char. But for SB applications, it does perform a WideCharToMultiByte, but would do nothing special in this case since the RES file does not have Japanese Unicode.

Moderator: Formatted hex dump.

[Vidar Hasfjord]

In my test Unicode application, I have in the RC file [an include of "japan.rc", in which I use a "pragma code_page"]

Herein lies the problem; the pragma "code_page" is not recognised within included files. You have to insert the pragma in the main resource file before including "japan.rc".

This is mentioned in the resource compiler documentation I linked: "This pragma is not supported in an included resource file (.rc)."

http://msdn.microsoft.com/en-us/library/windows/desktop/aa381031.aspx

Try again, and let me know if the world is a sound place. :-)

[Joe Slater]

insert the pragma in the main resource file before including "japan.rc".
 

Tried that.

let me know if the world is a sound place
 

The world is a sound place. :-)

With this revelation, I retract my synopsis that converting the RC files to Unicode might be a breaking change. Old compiler tools (e.g., Borland) would probably choke, but that breaking change is already in place with forcing C++11 compliance. So it's a mute point.

It would need to be made clear for OWLNext developers that the editing of such files requires a Unicode-friendly text editor.

I would also suggest that in conjunction with this changing of RC files for internationalization, that OWLNext better manage these resources, and comply with the standards set in place.

For instance, OWLNext already checks when loading resources (e.g., LoadString) for the standardised DLL naming convention (e.g., it searches for ENU.DLL first, before checking the EXE) for multi-language support. It dynamically builds the 3-character international name for the DLL based on the code page in place.

http://msdn.microsoft.com/en-us/library/8fkteez0.aspx
http://www.the-localization-tool.com/language-codes-mfc/

Although the above links are MFC, I believe OWLNext has implemented the same procedure.

While it's customary to include the "base" language (i.e., English as been set as the international language) in the EXE file as a fallback since loading a DLL module could fail, we could make available in the distribution files a JPN.DLL (and in the future any other languages supported) such that customised re-compilation isn't required.

Secondly, the management of resource IDs is still rather old-fashioned and conflicts are easy to introduce. Windows has its own set of "reserved" IDs. OWLNext has its own set of "possibly used" IDs. And then the application itself would no doubt have its own. There has to be a better way of managing this information to avoid introducing duplicate IDs. Admittedly, this change doesn't belong with this ticket.

[Joe Slater]

Forget the DLL distribution; that was rather stupid. :-/ User apps will no doubt have their own to include.

Instead, provide the tools/documentation to make it easy to generate such DLLs.

[Vidar Hasfjord]

The world is a sound place. :-)

Great to hear. A little doubt was starting to creep in.

I just realised that a transition to Unicode source format for the resource files makes the current organisation workable, and that it currently is not. As it is now, we have multiple translations in one file, while we at the same time rely on file inclusion to bring the resources for the different components together, and as we have seen, file inclusion and code page control (pragma "code_page") do not work together. However, with Unicode, this should all work fine.

Having multiple translations in the same file does not allow resources for each language to be built separately (unless we introduce some obscuring preprocessor conditionals), but I think that is a small price to pay for the convenience and maintainability of the current scheme. Having the translations close together makes it more likely that translations are kept in sync as resources are added, changed and removed.

Size-wise, I do not think it is a problem to include all translations in one. OWLNext does not contain much in terms of resources. And if someone really needs the resources for each language separated, it should still be possible to achieve by simple post-processing of the resulting binary resource file; e.g. copy only one language into a new binary. I guess existing resource editors can do that easily.

And the current scheme is not a problem with regard to concurrent editing by multiple translators either, since our source code version control and merging procedures should handle integration with ease.

Time to take it to the next level? I propose you start a thread about translation over at the Discussion forum to gather interest and recruit translators. Then, if you feel ready to make your first wiki edit (go on!), head over to the Roadmap page, and add translation to the proposed feature list for version 7!

PS. I can provide a starting point for Norwegian.

[Vidar Hasfjord]

@joeslatersf wrote:

Sorry for all the changes… [r2936], [r2937], [r2938], [r2939]. Had a bit of trouble with VS2013 RC. It should be okay now.

Note that these revisions cause a regression; the introduction of escape sequences corrupts the Shift JIS encoding of the Japanese text. However, due to lack of use and support, the Japanese translations were altogether removed in [r6766].

See [feature-requests:#86] for future translations.