Как стать автором
Обновить

Комментарии 32

Код картинками — что-то новенькое :)

Ниже замечания по делу:
1. Для строковых ресурсов так, как вы написали, не напишешь.
Вот правильный пример:
<string name="welcome_messages">Hello, %1$s! You have %2$d new messages.</string>

2. Plurals не всегда корректно работают с локалями.
3. Для облегчения перевода одинаковые строки можно объединить в одну, а остальные ссылать на нее:
<string name="my_string">111</string>
<string name="your_string">@string/my_string</string>

4. Чтобы проще было разделять ресурсы по блокам, не обязательно использовать конструкцию, как у вас
<!-- Работает -->
// Тоже работает!
<string name="...">...</string>
Тот момент когда комментарий к статье на уровне полезной статьи :)
Статья полезная, а из моего комментария реально полезен пожалуй только 3 пункт.
Но спасибо :)
  1. Можно и так, как в статье. Цифры нужны только для изменения порядка использования параметров.
  2. А можно вообще регионы использовать.
По 1 замечанию, еще с год назад у меня так не выходило написать, странно. Сейчас попробовал и всё сработало как часы, спасибо.
По 2 пункту — о каких регионах речь?
Сейчас это работает только для 1 параметра.
При наличии 2 и более будет выдана ошибка:
Error:(1264) Multiple substitutions specified in non-positional format; did you mean to add the formatted=«false» attribute?
Наверное потому мы везде использовали %1$, даже при наличии лишь 1 параметра — выглядит целостнее.
  1. Выше приведен пример, что все работает.
  2. В статье был сделан акцент на разделении строк, а ваш пункт №3 категорически этому противоречит.
  3. Я бы сказал, что это зависит от code style, в xml не принято ставить такого типа комментарии
    // Also works
По поводу пункта №3:
Мне кажется, что дублирвать значения в XML смысла никакого нет. Главное, чтобы Java-код ссылался на разные строки.
Принцип
Если вы используете разные строки с начала — вам бы пришлось модифицировать лишь strings.xml файл.
соблюдается.
4. когда строковых переменных очень много в одном файле даже поблочная разбивка и комментарии не помогают, мы сначала делили на разные файлы, а сейчас так и вообще для крупных блоков-экранов используем свои res-папки.
1) в десятках проектов нигде не встречал %1$s, везде было через %s, что самое интересное, так в документации показываются оба варианта, но во всех «официальных» sample я видел только %s, так что считать какой-то из вариантов неправильным, а единственный истинным — это абсолютизм на уровне ситхов
2) активно пользую в проектах, в т.ч. с right-to-left локалями, пока ни разу не корректностей не встречал, буду ОЧЕНЬ благодарен за конкретные локали или проблемные варианты использования
3) поддержу автора — ссылки на строки внутри хорошо, если мало локалей, но как только переваливает через 10 языков и в команде от 5 человек, которые паралельно работают с строковыми ресурсами, то это превращается в постоянный рефакторинг строковых ресурсов, проще сразу разделять сразу разделять
4) // — недопустимо для xml, и пока мало локалей то всё ок, но если приходится, ДАЖЕ ИНОГДА, прибегать к сторонним утилитам для сверки и консолидации переводов — это будет первое место для ругани
В десятках своих проектов? В десятках опенсорсных? В десятках фрилансовых на сапорте?
Не пытаюсь что-то доказать, но я встречал лишь несколько реально крупных проектов, написанных не мной. Примером может послужить Telegram. По ссылке вот тут xml для русской локализации — ССЫЛКА и там нету Plurals и %s. Наверное о чем-то это говорит у проекта с многомилионной аудиторией. Или вы думаете, что они просто не умеют?

По поводу ссылок на свои же ресурсы — это же даже не рекомендация, я написал что можно так делать. Как плюс — можно добиться существенной экономии на переводе.
По // тоже самое, так можно, но я же не настаиваю :)
т.е.
2. Plurals не всегда корректно работают с локалями.
это просто предположение? спрашиваю серьезно, так как активно ими пользуюсь при разработки или не трогаю их при рефакторинге

сорри если показалось сильной критикой с моей стороны, просто я прывик что 90% стоимости кода — это его поддержка и в данном случаи Ваши варианты (3 и 4) ведут к усложнению саппорта
К сожалению, дело давнее, потому и личных пруфов по Plurals не предоставлю, но это не предположение точно. Помню лишь, что проблемы были именно с локализацией. Гугл нашел как минимум одну проблему с ними, когда quantity равна нулю ССЫЛКА.
У нас на проектах используется MessageFormat.
Спасибо, полезно для развития
все кто жалуется на логику жалуются, по сути, на стандарт (unicode), с самими plurals проблем нет
также многие путают порядковые и количественные, что также вызывает необоснованный негатив
пробежался по stackoverflow
не одной заявления о некорректной работе strings plurals

как правило strings plurals — везде отмечен как правильный ответ на вопрос об локализации множественных
по указаной Вами ссылке не нашел ни одного места, где бы plurals вообще можно бы было использовать (просто небыло потребностей)
Выше я ответил — плохо пробежался значит.
Вот комментарий по проблемам с Plurals от vikarti, помимо моей ссылки на SO — #comment
там пролема не с plurals а с восприятием людьми стандарта unicode на котором он основан

Не стоит для аргументации использовать telegram. Он (там один разработчик клиента) переписал половину андроид, даже саппорты гугловые не использует, я не удивлен, что и в строках он что-то не применяет.

Вы избирательно читаете комментарии. Уже обсудили, что %s работает только при наличии 1 параметра. При наличии 2 и более — обязательно нумеровать их. Стиль и код выглядит целостнее, когда всё одинаково. Про plurals тоже обсудили уже, они могут навредить при работе с локализациями, при этом только на старых версиях андроида вроде как. Да и MessageFormat более гибок, чем телеграм и пользуется.
Почему не стоит его использовать при аргументации? Если проект имеет многомиллионную аудиторию и что-то не использует — стоит задуматься «почему?». Я исследовал их исходники, код не идеален с точки зрения читабельности, но фрагменты не используются в угоду скорости и плавности анимаций, коих с фрагментами объективно не добиться. Класс BaseFragment есть, просто он не extends Fragment.

Странно, что автор не участвует в дискуссии, мне его статься витися интересной.

Я отвечаю на те комментарии, на которые считаю необходимым.
Не пойму аргументации о единстве стиля. А чем "везде, где один аргумент, писать %s" не стиль? Если изменится количество аргументов, все равно код и строку менять придется.
Количество пользователей вообще никак не коррелирует с качеством кода и используемых подходов. Что телеграмм на практике доказывает. Он занимается велосипедостроением, оправдывая это стремлением к стабильности. Если ресурсы телеграмма позволяют писать собственную реализацию sqlite, им везёт, большинство проектов к такому не готовы. Да и смысла нет.

Множественное написание string.xml (в единственном числе) это много ошибок, или так и задумано?
Проверил, во всех проектах всегда генерируется strings.xml
В статье тогда поисправляйте везде!
Ну по большому счету, имя файла не имеет никакого значения.
Для себя заметил, что когда разделяешь сроки по экранам префиксами, то удобней пользоваться точками, нежели нижним подчеркиванием.
Я, например, делаю вот так, профит замечаешь позже, главное не скатиться с такого именования
<string name="history.status.received">Получен</string>
<string name="history.status.canceled">Отклонен</string>


В java коде правда это автоматом заменяется на такую конструкцию
R.string.history_status_receiverd

Но мне все равно нравится

А в чем профит, собственно? Который перевешивает нарушение code-style.

я рассматриваю разделение точкой только для смысловых блоков, тогда как в блоке нижним подчеркиванием разделяю слова, относящиеся к блоку.
например так
<string name="shopping_list.category.other">Другое</string>

На мой взгляд выгляди лаконичней, в сравнении с таким вариантом
<string name="shopping_list_category_other">Другое</string>
Как вариант, можно использовать такой гайд по строкам. Сам пользуюсь им.
с Plurals штатным есть проблемы на API ниже 11 (если оно еще актуально для вас) — читаем например http://www.dimasokol.ru/plurals-in-android/
На одном сравнительно недавнем проекте сначала было требование поддерживать 2.3.1 — пришлось использовать оберточку https://github.com/populov/android-i18n-plurals.

Подход с %1$s я например использую всегда. Даже зная что кроме русского и английского других языков в принципе не будет. И для моего open-source кода тоже.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации