C ++跨平台应用程序中本地化文本的最佳做法? [英] Bests practices for localized texts in C++ cross-platform applications?

查看:111
本文介绍了C ++跨平台应用程序中本地化文本的最佳做法?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在当前的C ++标准(C ++ 03)中,关于文本本地化的规范太少,这使得C ++开发人员在处理本地化文本时的生活比平时更艰难(当然,C ++ 0x标准将在以后为您提供帮助) ).

In the current C++ standard (C++03), there are too few specifications about text localization and that makes the C++ developer's life harder than usual when working with localized texts (certainly the C++0x standard will help here later).

  1. 响应(实时)应用程序:应用程序必须将无响应时间减至不明显",因此执行速度很重要.
  2. 本地化的文本:显示的文本被本地化为两种以上的语言,可能还有更多的语言-希望语言数量不固定,应该易于扩展.
  3. 在运行时定义的语言:不应在应用程序中编译文本(每种语言也不能拥有一个应用程序),您会在应用程序启动时获得所选的语言信息-这意味着需要加载某种文本
  4. 跨平台:应用程序在编写代码时就考虑了跨平台(Windows-Linux/Ubuntu-Mac/OSX),因此本地化文本系统也必须跨平台.
  5. li>
  6. 独立应用程序:该应用程序提供了运行它所需的全部功能;它不会使用任何环境库,也不会要求用户安装操作系统以外的任何内容(例如,大多数游戏).
  1. responsive (real time) application: the application has to minimize non-responsive times to "not noticeable", so speed of execution is important.
  2. localized texts: displayed texts are localized in more than two languages, potentially more - don't expect a fixed number of languages, should be easily extensible.
  3. language defined at runtime: the texts should not be compiled in the application (nor having one application per language), you get the chosen language information at application launch - which implies some kind of text loading.
  4. cross-platform: the application is be coded with cross-platform in mind (Windows - Linux/Ubuntu - Mac/OSX) so the localized text system have to be cross platform too.
  5. stand-alone application: the application provides all that is necessary to run it; it won't use any environment library or require the user to install anything other than the OS (like most games for example).

在这种应用程序中用C ++管理本地化文本的最佳实践是什么?

去年我调查了,我唯一确定的是您应该使用std::wstringstd::basic_string<ABigEnoughType>来操纵应用程序中的文本.我停止研究是因为我正在研究文本显示"问题(在实时3D情况下),但是我猜想有一些最佳实践可以管理原始C ++中的本地化文本,而不仅仅是使用Unicode"

What are the best practices to manage localized texts in C++ in this kind of application?

I looked into this last year that and the only things I'm sure of are that you should use std::wstring or std::basic_string<ABigEnoughType> to manipulate the texts in the application. I stopped my research because I was working more on the "text display" problem (in the case of real-time 3D), but I guess there are some best practices to manage localized texts in raw C++ beyond just that and "use Unicode".

因此,欢迎所有最佳实践,建议和信息(跨平台让我觉得很难)!

So, all best-practices, suggestions and information (cross-platform makes it hard I think) are welcome!

推荐答案

在一家名为Black Lantern Studios的小型视频游戏公司中,我是《 Lionel Trains DS》游戏的首席开发人员.我们本地化为英语,西班牙语,法语和德语.我们预先了解所有语言,因此在编译时包括它们是唯一的选择. (您将它们刻录到ROM中)

At a small Video Game Company, Black Lantern Studios, I was the Lead developer for a game called Lionel Trains DS. We localized into English, Spanish, French, and German. We knew all the languages up front, so including them at compile time was the only option. (They are burned to a ROM, you see)

我可以为您提供一些我们所做的信息.根据播放器的语言选择,我们的字符串会在启动时加载到数组中.每种单独的语言都进入一个单独的文件,所有字符串都以相同的顺序排列.字符串1始终是游戏的标题,字符串2始终是第一个菜单选项,依此类推.我们将数组从enum锁定,因为integer索引非常快,而在游戏中,速度就是一切. (在其他答案之一中链接的解决方案使用string查找,我倾向于避免这种查找.)在显示字符串时,我们使用了printf()类型的函数来将标记替换为值. "火车3即将离开城市1."

I can give you information on some of the things we did. Our strings were loaded into an array at startup based on the language selection of the player. Each individual language went into a separate file with all the strings in the same order. String 1 was always the title of the game, string 2 always the first menu option, and so on. We keyed the arrays off of an enum, as integer indexing is very fast, and in games, speed is everything. ( The solution linked in one of the other answers uses string lookups, which I would tend to avoid.) When displaying the strings, we used a printf() type function to replace markers with values. "Train 3 is departing city 1."

现在要解决一些陷阱.

1)在语言之间,短语顺序完全不同.翻译成德语的"火车3即将离开城市1.",最后变成"从城市1出发,火车3正在离开".如果您使用的是printf()之类的字符串,并且您的字符串是"火车%d正在出发的城市%d.",则德语将最终说"从城市3出发,火车1正在发车. ",这是完全错误的.我们通过强制翻译保持相同的词序来解决此问题,但最终还是出现了一些断断续续的德语.如果要再次执行此操作,我将编写一个函数,该函数接受字符串和要从中放入值的从零开始的数组.然后,我将使用%0%1之类的标记,基本上将数组索引嵌入到字符串中. 更新:@Jonathan Leffler指出,符合POSIX的printf()支持使用%2$s类型的标记,其中2$部分指示printf()用第二个附加参数填充该标记.只要足够快,那将非常方便.自定义解决方案可能仍会更快,因此您需要确定并测试两者.

1) Between languages, phrase order is completely different. "Train 3 is departing city 1." translated to German and back ends up being "From City 1, Train 3 is departing". If you are using something like printf() and your string is "Train %d is departing city %d." the German will end up saying "From City 3, Train 1 is departing." which is completely wrong. We solved this by forcing the translation to retain the same word order, but we ended up with some pretty broken German. Were I to do it again, I would write a function that takes the string and a zero-based array of the values to put in it. Then I would use markers like %0 and %1, basically embedding the array index into the string. Update: @Jonathan Leffler pointed out that a POSIX-compliant printf() supports using %2$s type markers where the 2$ portion instructs the printf() to fill that marker with the second additional parameter. That would be quite handy, so long as it is fast enough. A custom solution may still be faster, so you'll want to make sure and test both.

2)语言的长度差异很大.有时英语中的30个字符有时会变成德语中的110个字符.这意味着它通常不适合我们放在上面的屏幕.对于PC/Mac游戏,这可能不太重要,但是,如果您在做任何必须在定义的框中包含文本的工作,则需要考虑这一点.为了解决这个问题,我们从其他语言的文字中去除了尽可能多的形容词.这样可以缩短句子,但保留其含义(如果失去一点味道).后来我设计了一个我们可以使用的应用程序,其中包含字体和方框大小,并允许翻译人员进行自己的修改以使文本适合方框.不知道他们是否曾经实施过.如果遇到此问题,您也可以考虑在文本上滚动区域.

2) Languages vary greatly in length. What was 30 characters in English came out sometimes to as much as 110 characters in German. This meant it often would not fit the screens we were putting it on. This is probably less of a concern for PC/Mac games, but if you are doing any work where the text must fit in a defined box, you will want to consider this. To solve this issue, we stripped as many adjectives from our text as possible for other languages. This shortened the sentence, but preserved the meaning, if loosing a bit of the flavor. I later designed an application that we could use which would contain the font and the box size and allow the translators to make their own modifications to get the text fit into the box. Not sure if they ever implemented it. You might also consider having scrolling areas of text, if you have this problem.

3)就跨平台而言,我们为本地化系统编写了几乎纯的C ++.我们编写了要加载的自定义编码二进制文件,并编写了一个自定义程序,以将语言文本的CSV转换为带有枚举和文件到语言映射的.h,以及每种语言的.lang.我们使用的最平台特定的东西是字体和printf()函数,但是无论您在哪里开发,都可以找到适合自己的东西,或者可以根据需要编写自己的东西.

3) As far as cross platform goes, we wrote pretty much pure C++ for our Localization system. We wrote custom encoded binary files to load, and a custom program to convert from a CSV of language text into a .h with the enum and file to language map, and a .lang for each language. The most platform specific thing we used was the fonts and the printf() function, but you will have something suitable for wherever you are developing, or could write your own if needed.

这篇关于C ++跨平台应用程序中本地化文本的最佳做法?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆