Является ли добавление строк с заполнителями (`{0}`) в ресурсы хорошей идеей?

Question

Я добавил строку в файл ресурсов. Мое приложение будет локализовано.
Но хорошая ли идея добавить строки с заполнителями ({0}) в ресурсы?
Что делать, если какой-то не технический специалист занимается локализацией? Есть ли у него способ напортачить, по незнанию?

Если это не очень хорошая идея, что мне делать?

Вот простой пример. Я буду использовать словари ресурсов WPF.

Пример:

// Resource1.resx
//        Name               |            Value
//---------------------------------------------------------------
// RELATIONSHIP_STATUS_MSG   | {0} is in relationship with {1}. 
//


class Program
{
    static void Main(string[] args)
    {
        string msg = string.Format(Resource1.RELATIONSHIP_STATUS_MSG, 
                                   "Romeo", "Juliot");
        Console.WriteLine(msg);
    }
}

Answer 1

Ну, я считаю, что это хорошая идея, потому что это простой и быстрый способ рендеринга параметризованных и локализованных строк.

Между прочим, как вы говорите в своем вопросе, нетехнические люди могут сломать ваши строки локализации, потому что они не понимают, что такое "{0}". У меня есть два «подхода» для решения этой проблемы

1. Просто обратите внимание, что нетехнические люди, поддерживающие локализованные строки, не должны заботиться о тексте в скобках.

2. Используйте именованные заполнители: "{some-identifier}" и просто используйте someTextResource.Replace("{some-identifier}", someTextVar).

Что касается 2-го, вы можете реализовать некоторый метод, принимающий IDictionary<TKey, TValue> экземпляр отношений замещения, где ключ - это идентификатор, который нужно заменить, и значение текста, который нужно заменить вместо идентификатора.

Answer 2

Зависит от .

Иногда у вас нет выбора, кроме как использовать заполнители, например, для динамических данных. В этом случае использование заполнителей, особенно пронумерованных ({0}, {1}, ...), является не только хорошей идеей, но и наиболее приемлемой идеей с точки зрения интернационализации. Это позволяет изменить порядок предложений во время перевода, что вы определенно хотите поддержать.
Что касается нетехнических людей ... Ну, если вы используете профессионального поставщика перевода программного обеспечения, с ними проблем не возникнет, они просто привыкли переводить подобные строки. Если вы хотите назначить услуги только общего переводчика, это может создать проблему. Но в этом случае я должен предупредить вас, что технические переводы специфичны : переводчики должны по крайней мере подчиняться общепринятым терминам программного обеспечения.

ОК, теперь на почему это зависит . По сути, форматирование строк с помощью string.Format () фактически является конкатенацией. Как я уже сказал, если у вас есть динамические данные, у вас нет выбора. Но если ваши данные статичны, и у вас всего несколько комбинаций, вы никогда не должны ни при каких обстоятельствах использовать заполнители (ни простые конкатенации строк с оператором конкатенации (+), ни более сложные с StringBuilder). Для статических данных вам просто нужно создать столько строк, сколько нужно.
Настоящая причина этого в том, что многие языки нуждаются в разных формах перевода в зависимости от контекста. Например, на языке моей матери (польский) мы используем различные формы женских и мужских существительных.
Это не просто теоретическая проблема: 4 года назад, когда я работал над локализацией, нам пришлось локализовать новое основное антивирусное программное обеспечение. Проблема была в том, что какой-то программист оптимизировал ресурсы, так что у нас было одно сообщение, похожее на это:

The {0} is inactive. To activate {0} click...

То, что было подставлено вместо заполнителя, было именем функции или программы. По-польски функция - женская, по программе - мужская. Что еще хуже, наш лингвист хотел добавить слова «программа» и «funkcja», в зависимости от того, что на самом деле было неактивно.
Очевидно, что мы (инженеры по локализации программного обеспечения) не смогли исправить проблему, не касаясь кода (что нам было запрещено делать, но это другая история ...).

Подведем итог:
Используйте заполнители, если вам действительно нужно. Дисковое пространство дешево. Избегайте конкатенаций (так как это не позволит переупорядочить переведенное предложение).
Не беспокойтесь о переводчике, но не забывайте давать им контекст (возможно, также инструкции). Для них важно знать , где будет отображаться ваша строка и , какие являются возможными значениями.

Answer 3

Если вы сделаете это, убедитесь, что вы задокументировали поведение нетехнических переводчиков.В противном случае у вас все будет хорошо.

Answer 4

Мне нравится соглашение по именованию Решарпера: __0__is_in_relationship_with__1__

Проясняет, какие аргументы ожидаются при использовании из кода:

string msg = string.Format(Properties.Resources.__0__is_in_relationship_with__1__,
                           "Romeo", 
                           "Juliet");

Answer 5

Я обычно придумываю схему именования для этих строк типа, чтобы они выделялись в коде.

Как и Strings.RELATIONSHIP_STATUS_MSG_FORMAT

Answer 6

Используйте автоматическое тестирование для проверки целостности файлов ресурсов, возвращаемых поставщиками переводов. В идеале предоставьте поставщикам инструменты, которые делают это во время перевода, чтобы как можно раньше выявить дефекты.

Answer 7

Это рекомендуемый подход, я думаю.Руководство для GNU GetText предлагает сделать это, например.

Как комментирует Эрно, убедитесь, что тот, кто делает перевод, знает, что означает {0}.

Преимущество этого подхода заключается в том, что вы можете контролировать, куда вставляются значения, а также часть форматирования значений.Вам не хватает плюрализма ценностей, но это уже другая дискуссия.

Answer 8

Даже если вы предоставляете документ для нетехнических переводчиков, все еще есть некоторые шансы, что они смогут его использовать (неосознанно), что в противном случае не станет проблемой, если вы сами разберетесь с таким делом. Я бы предпочел объединить строку.