ios开发语言本地国际化_开发人员软件本地化最终语言指南

ios开发语言本地国际化

There are lots of great guides out there for how to prep your product for internationalization and localization from an engineering perspective. Building software localization into your product right from the start — even if you’re not ready to expand beyond one locale just yet — saves you a tonne of work and headaches down the line.

关于如何从工程学角度为国际化和本地化准备产品的准备，有很多很棒的指南。 从一开始就将软件本地化构建到您的产品中，即使您尚未准备好扩展到一个区域之外，也可以节省大量的工作和繁琐的工作。

The effects of software localization cascade down to every aspect of development and post-development, from UX and interface design to the basic engineering and core functionality of your product, and to documentation, support, and marketing. With this in mind, getting a good grounding in the repercussions that designing for different locales has for the development process is a great idea for any software developer.

从UX和界面设计到产品的基本工程和核心功能，再到文档，支持和市场营销，软件本地化的影响可追溯到开发和后期开发的各个方面。 考虑到这一点，对于任何软件开发人员来说，在不同的区域进行设计对开发过程的影响都具有良好的基础是一个好主意。

We’ll start by explaining some basic concepts. Then we’ll look at examples of strings from different languages and explore the requirements that different locales have. Throughout this post, we’ll refer to our fictional app “SuperApp” in our examples.

我们将从解释一些基本概念开始。 然后，我们将查看来自不同语言的字符串的示例，并探讨不同语言环境的要求。 在本文中，我们将在示例中引用虚构的应用程序“ SuperApp”。

语言环境与语言变体 (Locales vs. language variants)

It might be helpful to start by looking at what we mean by a locale. This is a term used both in the tech and translation industries to refer to a country-specific variant of a language. If you’re not from a multilingual background, you’d be forgiven for thinking that it’s sufficient to think about languages, such as English, Spanish and Swedish. If we want to make SuperApp available in one of these languages, surely it’s enough to translate the strings and be done with it?

首先了解一下语言环境的含义可能会有所帮助。 该术语在技术和翻译行业中都使用，指的是特定于国家/地区的语言变体。 如果您不是多语言背景的人，那么认为考虑英语，西班牙语和瑞典语等语言就足够了，这是可以原谅的。 如果我们想使SuperApp支持这些语言之一，那么就足以翻译字符串并完成它了吗？

The thing is, “language” is a fuzzy term, and nowhere near granular enough for our needs. Let’s start with English. It’s spoken natively by over 400 million people and is an official language in 55 sovereign states — a group of countries commonly referred to as the Anglosphere. The language isn’t uniform across the Anglosphere: there are dozens of national varieties, each with their own conventions for things like pronunciation, grammar and spelling standards, and even how dates and numbers are formatted.

关键是，“语言”是一个模糊的术语，而且在粒度上还不足以满足我们的需求。 让我们从英语开始。 它的母语是4亿多人，是55个主权国家(这是一组通常称为“盎格鲁圈”)的国家的官方语言。 整个英语圈的语言并不统一：有数十种国家变体，每种变体都有自己的约定，例如发音，语法和拼写标准，甚至日期和数字的格式。

You’re more than likely already familiar with the two biggest varieties: British English and American English. These national standards can be expressed with the IETF language tags en-GB and en-US respectively. The story is similar (albeit on a much smaller scale) for languages like Swedish ­– which is an official language in both Sweden (se‑SV) and Finland (se‑FI).

您很有可能已经熟悉两个最大的品种：英式英语和美式英语。 这些国家标准可以分别用IETF语言标签 en-GB和en-US 。 对于瑞典语这样的语言，情况也是如此(尽管规模要小得多)，这是瑞典( se‑SV )和芬兰( se‑FI )的官方语言。

But is this a locale? Well not quite. The tags above refer to the language variant only and do not include the user’s selected region settings. Region settings affect things such as how the date and time is expressed (e.g. ’31 December’ being written as 31/12 or 12/31, and whether to use 12- or 24-hour clock by default), how numbers are formatted (e.g. using a dot or a comma as the decimal separator) and where currency symbols are placed (e.g. before or after the amount, with or without a space). If we bundle these region settings up with the language variety, then we get our locale.

但这是语言环境吗？ 好吧，不完全是。 上面的标签仅指代语言版本 ，不包括用户选择的区域设置。 区域设置会影响日期和时间的表达方式(例如，“ 12月31日”被写为31/12或12/31 ，默认情况下是使用12小时制还是24小时制)，数字的格式设置(例如使用点或逗号作为小数点分隔符)以及放置货币符号的位置(例如在金额之前或之后，带有或不带有空格)。 如果我们将这些区域设置与语言种类捆绑在一起，那么我们将获得区域设置。

Although it’s important to understand the distinction between language variants and locales, thankfully the hard work of accounting for all the different date and number formats is done for you on most platforms.

尽管了解语言变体和语言环境之间的区别很重要，但值得庆幸的是，在大多数平台上，为所有不同的日期和数字格式进行的辛苦工作都是为您完成的。

On most operating systems, users can independently select their interface language and preferred region settings, meaning they can end up with locales that don’t necessarily align with national language variants. For example, many Icelanders use their computers in English, but with their region set to Iceland. This locale would be expressed as en_IS (note the use of an underscore as opposed to a hyphen).

在大多数操作系统上，用户可以独立选择界面语言和首选区域设置，这意味着他们最终可能会遇到不一定与本国语言变体保持一致的语言环境。 例如，许多冰岛人以英语使用他们的计算机，但是其区域设置为冰岛。 此语言环境将表示为en_IS (注意使用下划线而不是连字符)。

Although it’s important to understand the distinction between language variants and locales, thankfully the hard work of accounting for all the different date and number formats is done for you on most platforms. Apple, for example, provides a wide range of formatters that adjust things like the decimal indicator and date format automatically for the user’s selected region settings, even if those region settings don’t correspond to the interface language.

尽管了解语言变体和语言环境之间的区别很重要，但值得庆幸的是，在大多数平台上，为所有不同的日期和数字格式进行的辛苦工作都是为您完成的。 例如，Apple提供了广泛的格式化程序，即使用户所选择的区域设置与界面语言不对应，它们也可以自动调整十进制指示器和日期格式等内容，以适应用户选择的区域设置。

One final consideration is the aspect of hierarchy when it comes to language variants. Your app may only support one broad variety of English (en) or Spanish (es), for example, rather than country-specific variants. Even though you don’t support their local variant, most users will still prefer to use the broad international or regional variant of their language rather than a different language altogether.

最后要考虑的是语言变体中层次结构的方面。 例如，您的应用程序可能仅支持多种英语( en )或西班牙语( es )，而不支持特定国家/地区的变体。 即使您不支持其本地变体，大多数用户仍会喜欢使用其语言的广泛国际或区域变体，而不是完全使用其他语言。

Let’s take Spanish as an example. Most often, software is localised into Peninsular Spanish (the variety spoken in Spain) first. This national standard also acts as the ‘broad’ variety, and would sit at the top of the hierarchy, designated es. Now we’ve made SuperApp available in Spanish, we decide to offer a more tailored experience for our Latin American users by supporting their regional language variant, which is designated es‑419. Going further, we decide to offer our Mexican users an even more localised experience and translate our strings into Mexican Spanish, meaning we end up with an es‑MX variant as well. If a user’s preferred variant is not available, then they can cascade back up the list until they find their closest preferred language variant.

让我们以西班牙语为例。 通常，首先将软件本地化为西班牙半岛(西班牙语中所说的变种)。 该国家标准还充当“广泛”的品种，并且位于层次结构的顶部，指定为es 。 现在，我们已经以西班牙语提供了SuperApp，我们决定通过支持拉丁美洲的地区语言版本es‑419为我们的拉丁美洲用户提供更加量身定制的体验。 更进一步，我们决定为墨西哥用户提供更加本地化的体验，并将字符串转换为墨西哥西班牙语，这意味着我们最终还会使用es‑MX变体。 如果用户的首选变体不可用，则他们可以级联备份列表，直到找到最接近的首选语言变体。

为本地化编写字符串时要考虑的事项 (Things to consider when writing strings for localisation)

Now we’ve got a firm grip on locales, we can take a look at the ramifications of localisation when it comes to writing and concatenating (or segmenting) your software strings.

现在，我们已经牢牢把握了语言环境，我们可以看看在编写和连接(或分段)软件字符串时本地化的后果。

数字和日期 (Numbers and dates)

We’ve already briefly touched on the subject, so we should probably get this out of the way early. In almost all situations, there is essentially one golden rule to follow here: never hard-code date, time or number formats.

我们已经简短地谈到了这个主题，因此我们应该尽早解决这个问题。 在几乎所有情况下，这里基本上都遵循一条黄金法则： 永远不要硬编码日期，时间或数字格式 。

No matter what programming language and dev environment you’re using, there are fantastic date and number formatters available — either native or added through libraries such as Moment.js — that take care of all the hard work for you, returning perfectly localised dates and numbers that respect your users’ region settings. The best advice here is to rely solidly on these and save yourself a world of trouble.

无论您使用哪种编程语言和开发环境，都可以使用出色的日期和数字格式化程序(本机的或通过Moment.js之类的库添加的)来处理所有辛苦的工作，返回完美的本地化日期和遵守用户的区域设置的数字。 最好的建议是牢牢地依靠这些，为自己节省很多麻烦。

词尾 (Word endings)

In English, there are relatively few word endings (inflections) to consider. The vast majority of nouns are made plural by adding an -s or -es. When it comes to most verbs, we have only two forms in the present tense, for example sings and sing. However, many languages have a greater variety of endings than English, and these can affect more classes of words than nouns and verbs, for example many languages also inflect adjectives. The distribution can also vary by language: some languages, particularly Scandinavian ones, have less inflection than English on verbs, but more on adjectives.

在英语中，要考虑的单词结尾(词尾变化)相对较少。 通过添加-s或-es将绝大多数名词复数。 当谈到最动词，我们只有两个现在时态形式，例如唱歌 ， 唱歌 。 但是，与英语相比，许多语言的结尾种类更多，并且与名词和动词相比，它们可以影响更多的单词类别，例如，许多语言还使形容词变形。 分布也可以通过语言各不相同：一些语言，尤其是斯堪的纳维亚的，对动词少拐点不是英语，但更多的形容词。

Let’s take this example from Swedish:

让我们以瑞典语为例：

Där finns 1 rum ledigt på denne prisen.
There is 1 room available at this price.Där finns 10 rum lediga på denne prisen.
There are 10 rooms available at this price.

Here we can see that the verb finns is the same in both sentences, whereas in English we have two different forms, is and are. On the other hand, the adjective has changed: in the first sentence it is singular (ledigt) and the second it is plural (lediga).

在这里我们可以看到动词finns在两个句子中都是相同的，而在英语中我们有两种不同的形式， is和are 。 在另一方面中，形容词已经改变：在第一个句子它是单数(ledigt)和第二它是复数(lediga)。

This affects how we concatenate our strings. As a general rule, it’s always best to avoid chopping strings up wherever you can. The translator will be able to offer a better-quality translation if we leave the string as intact as possible. Another reason for this, as we’ll see below, is that word order can vary hugely between languages, so we should never assume that e.g. numbers will occur in the same position in the sentence.

这会影响我们如何连接字符串。 通常，最好避免在任何可能的地方切碎字符串 。 如果我们尽可能完整地保留字符串，翻译人员将能够提供更高质量的翻译。 另一个原因，正如我们将在下面看到的那样，不同语言之间的词序可能会有很大差异，因此我们绝不应该假设例如数字将出现在句子的同一位置。

复数 (Plurals)

In the Swedish example above we saw how word endings can change between singular and plural forms. In the Scandinavian languages and Finnish, we only have to worry about a singular and non-singular form. For other languages, the situation is slightly more complex. Let’s take an example from Icelandic:

在上面的瑞典语示例中，我们看到了单词结尾如何在单数和复数形式之间变化。 在斯堪的纳维亚语言和芬兰语中，我们只需要担心单数形式和非单数形式。 对于其他语言，情况稍微复杂一些。 让我们以冰岛语为例：

1 bíll fannst á þessu verði í nágrenninu.
1 car was found at this price nearby.12 bílar fundust á þessu virði í nágrenninu.
12 cars were found at this price nearby.21 bíll fannst á þessu virði í nágrenninu.
21 cars were found at this price nearby.

The first two sentences in this example show the same singular–plural distinction we’ve seen so far: when the number is more than 1, there is a different ending for the word. The singular word is bíll “car”, the plural word is bílar “cars”. However, Icelandic also requires numbers ending in -1 (with the exception of 11) to use the singular form, whereas other languages, including English, might have the plural form. This is because of the way the number is constructed in Icelandic: 21 expands to tuttugu og einn “twenty and one”, so we’re literally saying “twenty and one car”. This is something we need to take into consideration in our logic when deciding which form of a string to serve up in Icelandic.

到目前为止，此示例中的前两个句子显示出相同的单数/复数区别：当数字大于1时，该单词的结尾将有所不同。 奇异字法案 “汽车”，复数词是比拉尔 “汽车”。 但是，冰岛语还要求以-1结尾的数字( 11除外)使用单数形式，而其他语言(包括英语)可能具有复数形式。 这是因为数字是用冰岛语构造的： 21扩展为tuttugu og einn “二十一”，所以我们的字面意思是“二十一汽车”。 在确定在冰岛语中使用哪种形式的字符串时，我们需要在逻辑上考虑这一点。

In the Slavic languages, we have to consider a different, even more complex set of rules. In Polish, for example, there are three possible forms to choose from, depending on the number used:

在斯拉夫语言中，我们必须考虑一套不同的甚至更为复杂的规则。 例如，在波兰语中，根据使用的数字，可以选择三种可能的形式：

1. A singular form (e.g. samochód “car”);

   单数形式(例如samochód “汽车”)；

2. A form used with 2, 3 and 4, and any numbers ending in -2, -3 or -4, except for 12, 13 and 14 (samochody);

   与2、3和4以及任何以-2，-3或-4结尾的数字一起使用的格式，除了12、13和14( samochody )；

3. A form used with all other numbers (samochodów).

   与所有其他数字( samochodów )一起使用的表格。

In JavaScript, we could express this rule as follows:

在JavaScript中，我们可以将规则表达如下：

function returnPolishForm(i) {  var form = 'genPlural'; // Our default form
  var lastDigit = i.toString().slice(-1);  if(i==1) {
    form = ‘singular’; // If i is 1
  } else {
    if (lastDigit >= 2 && lastDigit <=4) {
      form = 'plural'; // If i ends in -2, -3, -4 and is not 12, 13, 14
      if(i >= 12 && i <=14) {
        form = 'genPlural'; // If i is 12, 13, 14
      }
    } else {
      form = 'genPlural'; // All other numbers
    }
  }  return form;}

Let’s take the example we used for Icelandic from above and apply it to Polish:

让我们以上面的冰岛语示例为例，将其应用于波兰语：

W okolicy znaleziono 1 samochód w tej cenie.
1 car was found at this price nearby.W okolicy znaleziono 2 samochody w tej cenie.
2 cars were found at this price nearby.W okolicy znaleziono 5 samochodów w tej cenie.
5 cars were found at this price nearby.W okolicy znaleziono 23 samochody w tej cenie.
23 cars were found at this price nearby.W okolicy znaleziono 25 samochodów w tej cenie.
25 cars were found at this price nearby.

Note how the word for “car” changes with the number. To serve the correct form of the string to the user, we need to add some logic that is specific to Polish. If we don’t do this, then we’ll introduce a grammatical error that in the best case detracts from the user’s experience, and in the worst case creates a severe misunderstanding.

注意“汽车”一词如何随数字变化。 为了向用户提供正确形式的字符串，我们需要添加一些特定于波兰语的逻辑。 如果我们不这样做，那么我们将引入一种语法错误，这种错误在最佳情况下会损害用户的体验，在最坏的情况下会造成严重的误解。

性别 (Gender)

Many languages have a feature called grammatical gender. These are essentially classes of nouns that inflect in a similar way. While they may be labelled masculine, feminine or neuter, a word’s grammatical gender doesn’t always align with its natural gender. In German, for example, the word for “girl”, Mädchen, is neuter. Gender doesn’t only affect nouns though: it has knock-on effects on adjective endings and pronouns as well.

许多语言都有一个称为语法性别的功能。 这些本质上是名词的类，以类似的方式进行变形。 尽管它们可能被标记为男性，女性或中性，但单词的语法性别并不总是与其自然性别一致。 例如，在德语中，“女孩”一词Mädchen是中性词。 性别不仅会影响名词：它还会对形容词的结尾和代词产生连锁React。

PronounsIn English, we use the neuter pronoun it to refer to inanimate objects. A typical string in SuperApp might look something like this:

代词在英语中，我们使用中性代词it指无生命的物体。 SuperApp中的典型字符串可能如下所示：

This document is over 50 MB in size. Would you like to send it anyway?

In Icelandic, this would be:

在冰岛语中，这将是：

Þetta skjal (n.) er yfir 50 MB að stærð. Viltu senda það (n.) samt?

The word for ‘document’, skjal, is grammatically neuter (n.). As a programmer, it may be tempting to split this message into two strings, as we have two sentences. Then if we need to swap out the first string, say to refer to a photo instead of a document, we can just concatenate them at runtime. However, if we change ‘document’ to ‘photo’ here, we get an ungrammatical construction in Icelandic (indicated by the asterisk):

语法上的“文档”一词skjal是中性的(n。)。 作为程序员，由于我们有两个句子，因此可能很想将此消息分成两个字符串。 然后，如果我们需要换出第一个字符串，例如引用照片而不是文档，则可以在运行时将它们串联起来。 但是，如果在此处将“文档”更改为“照片”，则会得到冰岛语的非语法结构(以星号表示)：

Þessi mynd (f.) er yfir 50 MB að stærð. Viltu senda *það (n.) samt?

The problem stems from the fact that mynd is feminine (f.), but það is neuter. This means that the gender doesn’t agree, making this pair of sentences ungrammatical. Instead of það, we should have the feminine pronoun hana (literally ‘she’), which refers back to mynd. The better solution then is to keep these sentences together in one string and allow the linguist to translate it as one block.

问题源于事实，即mynd是女性(f。)，而það是中性的。 这意味着性别不同意，使得这对句子不合语法。 代替theað ，我们应该使用女性代名词“ hana” (字面意思是“她”)， 该词指代mynd 。 更好的解决方案是将这些句子放在一个字符串中，并让语言学家将其翻译成一个整体。

AdjectivesGender also affects how we address users. In English, particularly in user interfaces, we tend to see a lot of structures like this:

形容词性别也影响我们对用户的称呼。 用英语，尤其是在用户界面中，我们倾向于看到很多这样的结构：

Are you sure you want to delete this folder?Are you ready to turn on your camera and microphone?

These kinds of sentences work great in English regardless of the gender and number of the people we’re addressing. However, in languages such as Spanish that mark gender on adjectives, we need to account for feminine and masculine forms in order to be inclusive:

这类句子在英语中效果很好，无论我们要与之交谈的性别和人数如何。 但是，在诸如西班牙语之类的在形容词上标记性别的语言中，我们需要考虑女性和男性形式，以便具有包容性：

¿Estás seguro/segura que quieres eliminar esta carpeta? ¿Estás listo/lista para encender tu cámara y tu micrófono?

In the first example, the translator can solve the problem somewhat creatively by rephrasing it to ¿Seguro que quieres eliminar esta carpeta?, which can be translated as ‘Is it certain that you want to delete this folder?’. This construction avoids addressing the user directly with an adjective.

在第一个示例中，翻译者可以将问题改写为“ Seguro que quieres eliminar esta carpeta？ ，可以翻译为“确定要删除此文件夹吗？”。 这种构造避免了用形容词直接与用户打交道。

However, the second phrase is more challenging to rework without addressing the user directly, so here we need to include both the masculine listo and the feminine lista to avoid excluding female users.

但是，第二个短语在不直接针对用户的情况下进行重做更具挑战性，因此在这里我们需要同时包含男性利斯托和女性利斯特，以避免排斥女性用户。

When writing strings, it’s good practice to avoid addressing the user directly with adjectives if you can help it. While a good translator will always find a solution, sometimes it might not be as neat as in English, and it could use more characters and subsequently take up more space in the UI.

编写字符串时，如果可以帮助，最好避免使用形容词直接与用户打交道。 一个好的翻译总是会找到解决方案，但有时它可能不如英语那样整洁，它可能使用更多的字符，从而在UI中占用更多空间。

文字伸缩 (Text expansion and contraction)

As we’ve seen above, translation can drastically alter the length of software strings. Some languages require more words or characters to express the same meaning as in English, whereas others may require fewer. Averages published by IBM show the number of characters in a string may increase by up to 200%, and that this is most likely to happen in the shortest strings, typically those below 10 characters. French, Italian and Spanish are all languages that see character expansions in this range. For the Nordic languages, your strings may actually contract in certain contexts as well. For example:

正如我们在上面看到的，翻译可以大大改变软件字符串的长度。 某些语言需要更多的单词或字符来表达与英语相同的含义，而其他语言则需要更少的单词或字符。 IBM发布的平均值显示，字符串中的字符数最多可以增加200％，最有可能出现在最短的字符串中，通常是少于10个字符的字符串。 法语，意大利语和西班牙语都是在此范围内看到字符扩展的所有语言。 对于北欧语言，您的字符串实际上也可能在某些情况下收缩。 例如：

Another thing to note from the example phrases here is how the word order can vary from language to language. Notice how in Spanish, the verb comes at the start of the sentence and our photo count is pushed further down. In Finnish, the album name is pushed up to the top of sentence, directly following albumista ‘from the album’.

从此处的示例短语中要注意的另一件事是单词顺序如何随语言而变化。 请注意，西班牙语中的动词如何出现在句子的开头，而我们的照片计数进一步降低了。 在芬兰语中，专辑名称被直接推至句子的顶部， 紧接在专辑专辑“ from the album”之后。

Also note how the punctuation varies from language to language. Each has slightly different conventions for things like speech marks. English uses “ ”, whereas Icelandic uses „ “ and French uses guillemets « » (with a space either side of the enclosed word).

还要注意标点符号在不同语言之间是如何变化的。 每种语言对于语音标记的约定都有一些不同。 英语使用“”，冰岛语使用“”，法语使用guillemet s«»(在封闭词的两边都有空格)。

For this reason, we should avoid syntax like this:

因此，我们应避免使用以下语法：

var string = photoCount.
             .photosWereDeleteFromAlbumString.
             .'“'.albumName.’”.’;

The preferred syntax would contain placeholders that the linguist is free to move at will, which you can then replace with variables at runtime:

首选语法将包含占位符，语言学家可以随意移动这些占位符，然后可以在运行时将其替换为变量：

// English
'{photoCount} photos were deleted from the album “{albumName}”.'// Finnish
'Albumista ”{albumName}” poistettiin {photoCount} valokuvaa.'

Note that the above examples don’t account for singular–plural distinctions — further logic is required to accommodate for those.

请注意，以上示例并未考虑单数与复数的区别，因此需要进一步的逻辑来适应这些区别。

语境是本地化人员的关键 (Context is key for localisers)

The thing that perhaps best equips a linguist to be able to translate your strings successfully is adequate context. Knowing when and a where a string appears enables the translator to make a whole range of linguistic decisions and ultimately provide a correct, high-quality and consistent localisation of your software.

也许最好的语言学家才能成功地翻译您的字符串是适当的上下文。 知道何时出现字符串以及何时出现字符串使翻译人员能够做出各种语言决策，并最终为您的软件提供正确，高质量且一致的本地化。

We recommend sticking to these guiding principles:

我们建议您遵循以下指导原则：

1.将您的产品交给翻译人员 (1. Get your product into the hands of your translators)

It’s crucial to loop translators into your development process early. Even if you’ve not yet delivered your first public release, it’s vital that linguists understand your app’s purpose and how your UI is laid out. Giving them access to pre-release versions means you save yourself from future headaches and endless rounds of feedback and feedback implementation.

尽早让翻译人员进入您的开发过程至关重要。 即使您尚未发布自己的第一个公开发行版，语言学家也必须了解您的应用程序的用途以及用户界面的布局，这一点至关重要。 为他们提供预发布版本的访问权限意味着您可以避免日后的麻烦以及无数轮的反馈和反馈实施。

2.提供当地背景 (2. Provide local context)

Software strings can be as short as one word. They might consist of a single verb: ‘delete’ for example. But is this verb functioning as an imperative (giving a command) or is just an infinitive (the dictionary form of the verb)? In English they look the same, but that’s not necessarily the case in other languages. To enable the translator to make the right choice, give them access to view surrounding strings even if they’ve already been translated, or even better, provide screenshots. Some tools can automate this process for you.

软件字符串可以短至一个单词。 它们可能包含一个动词：例如“删除”。 但是，该动词是充当命令性命令(发出命令)还是只是不定式(动词的字典形式)？ 在英语中，它们看起来相同，但在其他语言中则不一定。 为了使翻译者能够做出正确的选择，即使他们已经被翻译，也可以提供屏幕截图，使他们能够查看周围的字符串。 一些工具可以为您自动执行此过程。

3.为您的翻译提供其他翻译的权限 (3. Give your translators access to other translations)

If you’ve already localised into several languages or variants, giving translators access to those can make a world of difference, especially for closely related languages. For example, if you’ve already localised into Swedish and are now adding Danish and Norwegian, giving your translators access to the Swedish strings in a translation memory will help answer a lot of questions they’ll have, and may even allow them to recycle some existing translation solutions.

如果您已经本地化为多种语言或变体，则为翻译人员提供访问这些语言或变体的机会可能会有所不同，尤其是对于紧密相关的语言。 例如，如果您已经本地化为瑞典语，并且现在要添加丹麦语和挪威语，那么让翻译人员访问翻译记忆库中的瑞典语字符串将有助于回答他们将遇到的许多问题，甚至可能允许他们回收一些现有的翻译解决方案。

4.保持沟通畅通 (4. Keep an open line of communication)

Translators are used to surmising the meaning of a text from the context they have available, but sometimes they just don’t have the key information to hand that would allow them to choose the right translation. Be receptive to translator queries and respond with as much information and context as you can.

译者习惯于从可用的上下文中推测文本的含义，但有时他们只是手头上没有关键信息，无法使他们选择正确的翻译。 接受翻译查询，并以尽可能多的信息和上下文进行响应。

5.愿意适应您的产品 (5. Be open to adapting your product)

It’s impossible for any one developer to account for all of the nuances of every language variant they might want to localise into. Leverage the linguistic expertise of your translators to improve how you write, segment and concatenate your strings. For example, you might need to account for a different word order than you anticipated or you might need to adapt your logic to account for different word endings. Linguists can advise you on what works and what doesn’t for their language.

任何开发人员都不可能考虑到他们可能想要本地化的每种语言变体的所有细微差别。 充分利用翻译人员的语言专业知识，以改善您编写，分段和连接字符串的方式。 例如，您可能需要考虑与预期不同的单词顺序，或者可能需要调整逻辑以解决不同的单词结尾。 语言学家可以针对您的语言为您提供哪些有用的建议以及哪些不可行的建议。

We’ve covered a lot of ground in this post — but there’s always more that could be said. The main thing to take away is to approach software localisation with an open mind. Be prepared to give and receive feedback, adapt and iterate as you go, and take advantage of your translators’ linguistic expertise to deliver the best UX in your target locale.

我们在这篇文章中介绍了很多内容-但总有更多可以说的内容。 要带走的主要事情是以开放的心态进行软件本地化。 准备提供和接收反馈，随时随地进行适应和迭代，并利用翻译人员的语言专业知识在目标语言环境中提供最佳的用户体验。

Many developers are rightly wary about the localisation process. After all, you’re essentially entrusting somebody else to deliver your core user experience in a specific market. You want to make sure that you deliver on tone of voice, brand values and naturalness, not just having a grammatically correct translation. The key to this is a collaborative partnership and close, regular communication.

许多开发人员都对本地化过程保持警惕。 毕竟，您实质上是在委托其他人在特定市场中提供您的核心用户体验。 您要确保传达的是语调，品牌价值和自然感，而不仅仅是语法上正确的翻译。 实现这一目标的关键是合作伙伴关系和密切的定期沟通。

If you and your translators are all aligned around the same end goal of delivering a fantastic experience and they’re armed with the tools to make that happen, you’ll reap the many benefits that software localisation has to offer.

如果您和您的翻译人员都围绕提供出色体验的最终目标而齐心协力，并且他们配备了实现这一目标的工具，那么您将获得软件本地化所提供的许多好处。

Sandberg is the world’s centre of excellence for translation into the Nordic languages and English. Find out more about how we can help you achieve your software localisation goals on our website.

桑德伯格(Sandberg)是世界一流的北欧语言和英语翻译中心。 在我们的网站上找到有关我们如何帮助您实现软件本地化目标的更多信息。

翻译自: https://medium.com/swlh/the-ultimate-linguistic-guide-to-software-localisation-for-developers-3a7a6bc5f0a2

ios开发语言本地国际化