Явная множественная строка с использованием файлов iOS Stringsdict - PullRequest
3 голосов
/ 23 апреля 2020

Я начинаю изучать iOS Файлы Stringsdict и нашел какой-то существующий код в проекте, который использовал следующий синтаксис:

<key>zero</key>
<string>You no message.</string>

Согласно CLDR, zero является недопустимым множественным числом в Engli sh, и мы ожидаем использовать явные множественные числа (=0 при использовании ICU MessageFormat)

Я попытался найти, как использовать явные множественные числа в iOS файлах Stringsdict, и мог не найти способа добиться этого. Может ли кто-нибудь подтвердить, поддерживается ли это или нет?


Пример решения (я не могу их проверить, но, может быть, кто-то может?)

<key>0</key>
<string>You no message.</string>

Или

<key>=0</key>
<string>You no message.</string>

Дополнительная ссылка на явные правила множественного числа, являющиеся частью реализации CLDR формата сообщений ICU:

https://formatjs.io/guides/message-syntax/#plural -формат

= значение Это используется для соответствия заданному значению c независимо от множества категорий текущей локали.

Ответы [ 2 ]

2 голосов
/ 24 апреля 2020

Если вас интересует только правило zero, оно обрабатывается в файле .stringsdict для любого языка.

Источник: Замечания по выпуску Foundation для OS X v10.9

Если присутствует «ноль», это значение используется для отображения нулевого значения аргумента независимо от того, какое правило CLDR указывает для значения числового значения c.

В противном случае это единственные правила (зависит от языка): zero, one, two, few, many, others

1 голос
/ 25 апреля 2020

Краткий ответ

.stringsdict файлы не имеют возможности поддерживать явные правила множественного числа (кроме пользовательской реализации Apple zero, которая подробно описана ниже)

Подробный ответ

Обычная реализация CLDR:

  • Все правила, которые отсутствуют в CLDR для данного языка, будут игнорироваться
  • Если используется правило zero, оно будет использовать значения CLDR (большинство языков имеют 0 в качестве значения для zero). Это также включает в себя такие языки, как латышский, которые имеют 20, 30, et c. значения сопоставлены с zero, а также противоречит собственной документации Apple (это поведение было проверено):

Если присутствует «ноль», значение используется для сопоставления значение аргумента ноль, независимо от того, какое правило CLDR указывает для числового значения c.

Источник: Замечания по выпуску Foundation для OS X v10.9

Пользовательская (Apple) реализация CLDR:

  • Все языки могут использовать категорию zero из CLDR, даже если правило не определено для этого языка (ссылка здесь )
  • Предположительно, они реализовали это, чтобы упростить негативные формы предложений, что является распространенным случаем (это можно найти даже в их примерах ). Например, вместо того, чтобы писать:

У вас 0 писем.

Вы можете написать:

У вас нет писем.

  • Это очень распространенный случай использования, но обычно он не охватывается категориями CLDR, он используется с использованием явных значений. Например, в ICU MessageFormat вы можете использовать =0, а не zero для отрицательных форм.
    • Хотя это кажется удобным, это создает большую проблему, что если вы хотите использовать отрицательные формы для латышского языка, используя категорию zero? Вы просто не можете - в основном Apple нарушила лингвистические правила c, переписав CLDR .

Дополнительные сведения:

  • В CLDR есть только два языка, где zero не равно 0:
  • Ни iOS, ни macOS не доступны на латышских языках, но они поддерживают языковые настройки (форматы клавиатуры и даты)
  • Это означает, что, вероятно, есть несколько приложений, которые будут поддерживать латышский язык, если только у них нет ручного способа изменить язык внутри самого приложения (это менее распространенный сценарий для iOS которые обычно соблюдают настройки устройства)

Заключение

Совет № 1: Если вам нужно использовать латышский, вам, вероятно, следует избегать использования zero для отрицательного формы, и использовать вместо этого код с st звонит за пределы stringsdict файла

Совет № 2: Убедитесь, что ваш процесс перевода правильно поддерживает это поведение!

...