Явная строка множественного числа с использованием файлов iOS Stringsdict

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

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

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

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

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

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

Or

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

Дополнительная ссылка на явные множественные правила, часть реализации CLDR ICU MessageFormat:

https://formatjs.io/guides/message-syntax/#plural-format< /а>

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


ios localization internationalization messageformat cldr
person Nicolas Bouvrette    schedule 23.04.2020    source источник
comment
Можете ли вы объяснить, что вы подразумеваете под недопустимым множественным числом в этом вопросе? Это технический термин, с которым я не знаком? (Я согласен с тем, что ноль, безусловно, множественное число в английском языке, и этот строковый файл неверен. Я просто пытаюсь понять, что вы имеете в виду под недействительным здесь.) Я не понимаю, как это относится к MessageFormat. ICU объединяет ноль с другим (и, следовательно, множественным числом) в английском языке: >unicode-org.github.io/cldr-staging/charts/37/supplemental/ (это очень интересный вопрос; я просто хотел бы понять его лучше. Можете ли вы дать ссылку на ту часть CLDR, которую вы повторная ссылка?)   -  person Rob Napier    schedule 23.04.2020
comment
Да, правила для английского языка в CLDR (та же ссылка, которую вы предоставили) поддерживают только one и other. С моей точки зрения, файл Stringsdict — это просто пользовательская реализация Apple — ICU MessageFormat с точки зрения правил множественного числа. В MessageFormat есть способ явно перезаписать категории твердыми числами, чтобы повысить беглость (пример в вопросе). См. еще один пример здесь: formatjs.io/guides/message-syntax/#plural-format . Я не смог найти, поддерживает ли он также явные правила множественного числа, такие как официальный синтаксис, или он просто поддерживает правила, определенные в CLDR.   -  person Nicolas Bouvrette    schedule 23.04.2020
comment
Файл Stringsdict - это просто пользовательская реализация Apple - это ICU MessageFormat с точки зрения правил множественного числа. Почему вы в это верите? Я бы сказал, что Stringsdict — это реализация Apple системы перевода, которой также является MessageFormat. Это не означает, что у них есть что-то вроде одинаковых функций или даже целей. С какой проблемой перевода строк вы сталкиваетесь, которую не можете решить с помощью Stringsdict?   -  person Rob Napier    schedule 23.04.2020
comment
С моей точки зрения, ICU MessageFormat является стандартной реализацией CLDR (оба являются стандартами Unicode). Если бы Apple решила использовать правила множественного числа CLDR, я бы предположил, что они также будут включать явные правила множественного числа, чтобы сделать синтаксис множественного числа более свободным. Но, конечно, я нигде не мог подтвердить это, что наводит меня на мысль, что это не поддерживается в их реализации,   -  person Nicolas Bouvrette    schedule 23.04.2020
comment
Я согласен, что это почти наверняка не поддерживается. Я не могу придумать никаких причин полагать, что Apple основала этот формат на стандарте Unicode. У Apple десятилетиями была локализация, не привязанная к ICU (ICU был разработан для C++ и Java). Есть ли у вас конкретная проблема с переводом на iOS? Я уверен, что мы можем помочь вам решить эту проблему.   -  person Rob Napier    schedule 23.04.2020
comment
На самом деле я являюсь частью рабочей группы с Unicode (в MessageFormat), и у нас есть кто-то из Apple в этой группе :) CLDR также используется Apple для создания Stringsdict (это подтверждено в их документе). Для меня множественное число — это четко определенная проблема (стандарт Unicode), и явные правила должны быть частью любой реализации. Позвольте мне добавить к моему вопросу пример того, что я ожидаю от Apple.   -  person Nicolas Bouvrette    schedule 23.04.2020
comment
В вашем редактировании не является ли zero именно тем, что вы описываете (т. Е. Строка формата, используемая для числа 0)? Чем это отличается от This используется для соответствия определенному значению независимо от категорий множественного числа текущей локали, когда конкретное значение равно нулю? Когда вы говорите, что не можете проверить это, можете ли вы описать, какое поведение вы ожидаете, если тест будет пройден или не пройден?   -  person Rob Napier    schedule 23.04.2020
comment
так что да, я думаю, @paiv ответит на вопрос, который для меня довольно странный. Это означает, что с реализацией Apple они не могут поддерживать латышский и прусский языки, если только нет какой-то другой логики, которую я не понимаю?   -  person Nicolas Bouvrette    schedule 24.04.2020

Ответы (2)


arrow_upward
3
arrow_downward

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

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

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

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

person paiv    schedule 23.04.2020
comment
Вау, зачем Apple это делать? они построили свою логику поверх CLDR? знаем ли мы, как они могут поддерживать множественное число в латышском языке (unicode-org.github.io/cldr-staging/charts/37/supplemental/) или прусский (unicode-org.github.io/cldr-staging/charts/37/supplemental/), где ноль может иметь несколько значений? - person Nicolas Bouvrette; 24.04.2020
comment
@NicolasBouvrette на этих языках zero будет соответствовать правилам CLDR. Это английский, где zero является дополнительным. - person paiv; 24.04.2020
comment
Как вы можете подтвердить? Ни iOS, ни macOS не доступны на латышском языке, поэтому я подозреваю, что, вероятно, поэтому они внедрили это правило zero == 0, которое вы нашли в документации. Это говорит независимо от того, что указывает правило CLDR - person Nicolas Bouvrette; 24.04.2020
comment
Эта строка документации не является точной. Можно запустить приложение с AppleLanguages, установленным на lv_LV, чтобы проверить фактическое поведение. - person paiv; 24.04.2020
comment
То есть вы говорите, что протестировали его, и он работает на латышском языке? - person Nicolas Bouvrette; 24.04.2020

arrow_upward
2
arrow_downward

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

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

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

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

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

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

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

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

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

У вас 0 писем.

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

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

  • This is a very common use case but is typically not covered using CLDR categories, it is used by using explicit values. For example, in ICU MessageFormat you can use =0 and not zero for negative forms.
    • While this seems convenient, it creates a big problem, what if you want to use negative forms for Latvian using the zero category? You simply can't - basically Apple broke linguistic rules by overwriting the CLDR.

Дополнительные детали:

  • There are only two languages in the CLDR where zero does not equal 0:
  • Ни iOS, ни macOS не доступны на латышском языке, но поддерживают региональные настройки (форматы клавиатуры и даты).
  • Это означает, что, вероятно, есть несколько приложений, которые будут поддерживать латышский язык, если только у них нет ручного способа изменить язык внутри самого приложения (это менее распространенный сценарий для iOS, который обычно учитывает настройки устройства).

Заключение

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

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

person Nicolas Bouvrette    schedule 25.04.2020
comment
Просто поясню поддержку латышского языка: пользователи могут выбрать латышский в качестве предпочитаемого языка в iOS и macOS, и хотя пользовательский интерфейс системы не будет локализован на латышский язык, любое приложение, включающее латышскую локализацию, будет использовать его без необходимости включать ручной способ изменения языка. язык в приложении (подход, необычный для приложений на обеих платформах). Я предполагаю, что в устройствах, продаваемых в Латвии, латышский язык будет указан в качестве языка по умолчанию из коробки. Однако я также предполагаю, что носители латышского языка обычно используют большую часть своего программного обеспечения на языке, отличном от латышского. - person SeanR; 01.05.2020