0

In a C++ MFC project, before making choices of resource implementation, I'm looking forward to know the consequences on the language files and the subsequent translation process.

First, I know there are 3 approaches for language and resources files (.rc + .rc2 files) in MFC projects:

  • The native one (when you create a Windows project from the simplest template), you obtain a monolithic file .rc/.rc2 where languages and interfaces design will be mingled.
    • The edition can be done with Visual Studio or external tools like "RCLocalize".
  • The evolution of the native one, with separated languages. Since .rc files support C++ include, you can separate each language in a file and include them in the main .rc (found on Internet, don't know if it solves anything).
  • The Resource-only DLL, where you create a second project destined to carry resources. One per language. And in the main project a call to LoadLibrary / LoadLibraryEx.

So now, the question. Which approach gives a good and straightforward process for the delegation process of translation?

I have in mind the i18n process of sending ressources files to translation teams: "Here are 2 files, a reference and a target, plus a software to edit them (optional, depends on formats complexity)".

And the documentation I found on "Resource-only DLLs" don't say a word on how easy is the translation done.

Related :

Sandburg
  • 757
  • 15
  • 28
  • 1
    *"Since .rc files are just C++ files"* - They are not. [Resource files](https://learn.microsoft.com/en-us/windows/win32/menurc/about-resource-files) are text files, that are processed by the [resource compiler](https://learn.microsoft.com/en-us/windows/win32/menurc/resource-compiler). The resource compiler supports a subset of the C preprocessor, but that doesn't make .rc files *"C++ files"*. – IInspectable Feb 27 '23 at 09:31
  • Right, I edited to point the major element of this technic. But I could simply remove the second point, if it attracts too much attention (it's not the approach I would prefer), plus I can't find where I get this idea. It's not widespread. – Sandburg Feb 27 '23 at 09:36
  • As for the generic question on what file formats any given translator can handle, that's specific to the translator you are working with. If they can work with .rc files, then have them use those. For anything else you'll need to convert back and forth. Now all of that is a trivial issue. The hard problem is communicating with the translator on what each piece of text is used for. – IInspectable Feb 27 '23 at 09:41
  • *.rc* files converting is no trivial issue. Or maybe you know some good tools. Even with RCLocalize which makes it, there are still problems of encoding and separators to manage at the merge. I had the habit of Qt Linguist which was good. So now that I switch of ecosystem, I'm asking for advise. – Sandburg Feb 27 '23 at 09:50
  • @sandburg questions that search for stuff (like tools, libraries and books) are not allowed as these have no one correct answer and so we will get opinionated answers, arguments and spam. – Öö Tiib Feb 27 '23 at 10:59
  • I'm not searching for tools. I'm at the beginning of a path that leads to choose a project organisation. I'm asking if it's normal to be painful to translate a MFC project, or if it is straightforward (because the ecosystem is meant for that). Maybe it will need extra tools, maybe not. I don't know. – Sandburg Feb 27 '23 at 11:17
  • Both your comments make me thing you know something but you don't say. Like: I will have to convert my files. I'm stuck with rc files. The correct choice is already in my list. There is no correct choice. You suffered before me, and want everybody to suffer again (it's a joke). - If it's not a Stack question, who to ask? - Maybe I'm in a X/Y problem. Then I'm asking for questions in return. – Sandburg Feb 27 '23 at 11:24
  • 1
    .rc files are [well documented](https://learn.microsoft.com/en-us/windows/win32/menurc/resource-definition-statements). Translating between .rc files and a file format your translator understands (and back) is near trivial compared to the task of finding a translator that understands what they are working with. You cannot cut corners here: Your application will need to have .rc files, on way or another. The solution is rather straight forward. You'll have to become comfortable with how the system is designed to work first, though. I feel you're struggling to accept this. – IInspectable Feb 27 '23 at 12:06
  • 1
    We use the last approach. Splitting every language into its own DLL. We use RCWinTrans to create a language-RC file from a master-language-RC file. The tool is perfect. Also there is a translator module. We import the RC file into RcWinTrans. We send the new language DB file to the translator. He sees all changes and new entries. And gets support by the previous used phrases... we get the new translates RC file back and language DB back. Than we import this single language in our productive system. As long as there is no translation the text from the master or any other language can be used. – xMRi Feb 27 '23 at 12:22

0 Answers0