在便携式标准C/C ++代码中使用vc资源脚本 [英] using vc resource scripts in portable standard C/C++ code

问题描述

我正在创建一个库项目，该项目既可以在普通程序中使用，又可以在Windows和Linux中的dll文件中使用，因此，我想对一些错误字符串进行硬编码，以便在出现各种错误消息时使用. br/>

问题:我知道有两种方法可以完成.

1.创建一个名为errordesc.h的文件，并为每个错误创建一个常量字符串.
2.使用带有字符串表的资源脚本文件.

但是我的问题是，Linux程序是否支持资源脚本文件?因为如果Linux程序不支持使用资源脚本文件，那么除非有其他解决方案，否则我将不得不使用.h文件.

I am creating a library project which can be used in both a normal program and used in a dll file in both windows and linux, for that reason i want to hardcode some error strings for use in case of various error messages.


The problem: I know there are 2 ways in which it can be done.

1. Create a file called errordesc.h and create a constant string for each error.
2. The use of a resource script file with a stringtable.

My question however is wheather a resource script file is supported in linux programs? because if the use of a resource script file is not supported in linux programs, then I will have to use an .h file unless there is other solutions.

推荐答案

已查看 ICU资源管理 [

Have a look at ICU Resource Management[^]

ICU does this pretty well on various operating systems.

Best regards
Espen Harlinn

据我所知，您不能在Linux上使用Windows资源脚本，因此我将使用头文件.

As far as I know, you cannot use Windows resource scripts on Linux, so I would use a header file.

对于跨平台项目，当您可以将数据放在其他位置时，.rc文件是一个很大的禁止.通常，它应该仅包含必要的Windows特定内容，也许是versioninfo，清单和图标...

问题是:您稍后会计划本地化吗?如果没有，则将纯英文文本硬编码到您的源代码中. (当然，您可以将它们收集到一个集中的位置...)如果要进行本地化，请使用代码中需要当前语言正确字符串的描述性字符串代替字符串或int ID.好的，什么是语言字符串的正确位置???在我看来，它绝对不是可用于字符串的资源！

资源字符串表是世界上最不有用的东西之一. :-)我猜它的存在仅仅是因为我们是从远古时代继承而来的.例如，许多程序使用DL​​L中的程序提供本地化数据，将每种语言的翻译后的文本放入不同的dll中，并根据语言加载不同的dll.我的问题是:为什么要加载DLL只是为了从中获取语言的字符串?问题在于，您在互联网上阅读的内容并不是全部都是正确的，并且并非每个解决方案都是好的，因为它存在.这是我的共鸣，为什么值得花一些时间来存储另一种格式的本地化数据:

本地化通常由指定翻译的外部公司完成.他们的员工通常不是计算机科学家，他们往往会弄糟资源脚本文件，以后您将无法纠正它，如果是韩语或中文，请说，如果多行文本的情况更糟，那就太琐碎了如何换行，这在很大程度上取决于语言，因此通常无法手动纠正这些问题.如果搞砸了，那么您必须为它们重新发送东西，并且可能不得不进行不必要的往返，在最坏的情况下甚至可以推迟发布日期...

与其向它们发送一个裸露的.rc文件，不如向其提供一些精美的工具，好得多，例如一个Excel工作表，其中包含语言和列和行中的本地化键.关于Excel工作表的有趣之处在于，您甚至可以设置字体大小和列大小，以便它们立即具有WYSIWYG工具来包装多行文本.稍后，您可以将电子表格另存为utf8 xml，然后就可以轻松获取数据，也可以将其转换为不包含excel特定格式标签的xml，也可以将本地化数据保存为每个utf8文本文件语.这是跨平台且无忧的解决方案.如果正确的本地化很重要，那么编写一个加载您的自定义格式的加载程序很容易，而且值得一秒钟.这是一小段至关重要的代码，如果处理不正确，以后会很头疼.

即使您使用本地化支持，它的优良作法也是将默认语言(通常是英语)也添加到代码中.

In case of crossplatform projects the .rc file is a big no-no when you can put the data elsewhere. Normally it should contain only the necessary windows specific stuff, maybe a versioninfo, a manifest and an icon...

The question is: do you plan localization later? If not then hardcode the text in plain english into your source code. (You can of course collect them to a centralized place...) If you want localization then instead of the string or an int ID use a descriptive key string from the code that needs the right string for the current language. OK, what is the right place for the strings of a language??? Its definitely not a stringtable resource in my opinion!

The resource string table is one of the least useful things in the world. :-) I guess it exists just because we inherited it from ancient times. Many programs used that for example in DLLs to provide localization data, they put the translated text for each language into a different dll and they loaded a different dll depending on the language. My question is: whyz ooooh why to load a DLL just to get strings for a language from it? The problem is that not everything is true you read on the internet, and not every solution is good because it exists. Here is my resoning why is it worth investing a little bit of time to store localization data in another format:

Localization is usually done by an external company specilaizing in translation. Their people are often not computer scientists and they tend to screw up resource script files, and you won''t be able to correct it later lets say in case of korean or chinese - to make it worse in case of multiline text its not trivial how to wrap lines, it depends heavily on language so manually correcting these things on your side is often impossible. If something is screwed up then you have to resend the stuff for them and you might have to make unneeded roundtrips that in worst case is able to push even a release date...

Instead of sending them a bare .rc file its much better to provide them some fancy tools, like an excel sheet that contains the languages and the localized keys in the columns and rows. The funny about excel sheets is that you can setup even the font sizes and column sizes so they immediately have a WYSIWYG tool to wrap multiline text. Later you can save the spreadsheet as an utf8 xml and you can get data out of it easily and you can convert it to another xml that doesn''t contain excel specific formatting tags or you can save the localization data to separate utf8 text files per language. This is crossplatform and hassle free solution. Writing a loader that loads your custom format is easy and worths every second if correct localization matters. Its a small piece of code that is critical and makes you a lot of headaches later if isn''t done correctly.

Even if you use localization support its good practice to put the default language (usually english) into the code as well.

这篇关于在便携式标准C/C ++代码中使用vc资源脚本的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！