Comments 16
Я бы добавил пункт 0: глубоко вдохните-выдохните 3 раза и хорошо подумайте — а нужна ли вам локализация. Я сейчас наблюдаю пример программы, которая падает (выдает ошибку) пытаясь открыть свои конфиги. Т.к. разработчики вместо printf/scanf решили выпендриться с локалями, но на шаг вперед не подумали: в их же текстовом конфиге идущем по-умолчанию для дробных чисел используется точка. А когда файл загружается с местной локалью — запятая. Самое смешное что где-то внутри все равно продолжает использоваться хранение данных в текстовом представлении и там уже захардкожено использование точки, поэтому ручная правка не помогает и впоследствии числа все равно искажаются.
Нечто подобное было на IT Happens: одной программе требуется английская системная локаль, другой — русская. А программам надо работать в связке. Сейчас у меня отвалилась часть интернета и ITH недоступен, так что дайте ссылку, у кого есть…
А вот и неверно. Точка с запятой.
Это большая проблема при разработке многих продуктов, когда не уделяется внимание культуре строк при работе со сроками и их преобразовании в данные и обратно.
Очевидно, что в конфигах, файлах автоматизированного обмена и подобном, строчное представление данных всегда должно храниться в Invariant-культуре (которая должна использоваться и при обратном преобразовании).
Кстати, если говорить о .NET, то при разработке конфигов даже безобидный, на первый взгляд, оператор
string s = intVar.ToString()
может все сломать, т.к. в системе может быть не только переопределен знак минуса, но и даже сами цифры 0..9.
А вот .ToString(CultureInfo.InvariantCulture) мало то пишет в таких случаях
А то, что отображается на экране — как правило, с учетом текущей культуры системы (и преобразовывать введенные строки в данные с учетом нее).
Очевидно, что в конфигах, файлах автоматизированного обмена и подобном, строчное представление данных всегда должно храниться в Invariant-культуре (которая должна использоваться и при обратном преобразовании).
Кстати, если говорить о .NET, то при разработке конфигов даже безобидный, на первый взгляд, оператор
string s = intVar.ToString()
может все сломать, т.к. в системе может быть не только переопределен знак минуса, но и даже сами цифры 0..9.
А вот .ToString(CultureInfo.InvariantCulture) мало то пишет в таких случаях
А то, что отображается на экране — как правило, с учетом текущей культуры системы (и преобразовывать введенные строки в данные с учетом нее).
UFO just landed and posted this here
Браузер может определить, что a идет перед b, но не знает, идет ли ằ перед ã.
Неправда. Знает. Но с условием: нужно использовать INTL — Intl к нам приходит!
Надеюсь это не сильно нагло — вставлять ссылку на собственный пост?
Периодически меня беспокоит один вопрос:
Например, имеем веб-приложение с локализацией через GNU/Gettext.
Есть фраза, в которой одно слово должно быть ссылкой, например:
1. Можно было бы разделить эту фразу на две: сам текст и текст ссылки, но тогда переводчик сойдет с ума, выискивать в файле перевода эти строки, они могут находится далеко друг от друга.
2. Можно сделать подстановку урла ссылки через какой-нить sprintf или, например, через замену ключевого слова "{url}" на ссылку, но в этом случае в переводы попадает HTML, и строки становятся не просто строками, а строками с разметкой. Плюс что делать если у нас там на ссылке должна быть куча атрибутов (класс, айди, таргет…).
3. Можно было бы изобрести свой DSL и выводить в перевод что-то типа «Я согласен с {link: условиями использования продукта}.», но это как-то слишком сложно для такой простой задачи.
Как бы лучше поступить в такой ситуации? Как такие проблемы решают на тех же десктопных гуях, где нет такого языка разметки, как HTML?
Например, имеем веб-приложение с локализацией через GNU/Gettext.
Есть фраза, в которой одно слово должно быть ссылкой, например:
Я согласен с <a href="...длинная ссылка...">условиями использования продукта</a>.1. Можно было бы разделить эту фразу на две: сам текст и текст ссылки, но тогда переводчик сойдет с ума, выискивать в файле перевода эти строки, они могут находится далеко друг от друга.
2. Можно сделать подстановку урла ссылки через какой-нить sprintf или, например, через замену ключевого слова "{url}" на ссылку, но в этом случае в переводы попадает HTML, и строки становятся не просто строками, а строками с разметкой. Плюс что делать если у нас там на ссылке должна быть куча атрибутов (класс, айди, таргет…).
3. Можно было бы изобрести свой DSL и выводить в перевод что-то типа «Я согласен с {link: условиями использования продукта}.», но это как-то слишком сложно для такой простой задачи.
Как бы лучше поступить в такой ситуации? Как такие проблемы решают на тех же десктопных гуях, где нет такого языка разметки, как HTML?
Это вы зря, про простую задачу. DSL или строки с форматированием самое то.
Почти всегда имеет смысл обойтись первым вариантом. Просто потому, что переводчики чаще всего твой текст прогоняют через гугл-транслейт, исправляют явные ошибки и отдают заказчику, не вникая особо в смысл отдельных фраз — стоит ли упрощать переводчику работу, если он ее и так не выполняет как положено?
А если таки попадается качественный переводчик, который хочет не халтурить, а сделать вещь, то он все равно столкнется со множеством двусмысленных коротких фраз, которые вне контекста могут быть переведены по разному и иметь разный смысл. Потому после загрузки перевода в проект, качественный переводчик должен его пересмотреть и внести правки.
А если таки попадается качественный переводчик, который хочет не халтурить, а сделать вещь, то он все равно столкнется со множеством двусмысленных коротких фраз, которые вне контекста могут быть переведены по разному и иметь разный смысл. Потому после загрузки перевода в проект, качественный переводчик должен его пересмотреть и внести правки.
Я делаю так: «Я согласен с {linkBegin}условиями использования продукта{linkEnd}.»
Где в {linkBegin} находится открывающий тег ссылки, в {linkEnd} — закрывающий.
Тогда переводчику понятен контекст, и он даже может изменить положение ссылки в тексте.
Где в {linkBegin} находится открывающий тег ссылки, в {linkEnd} — закрывающий.
Тогда переводчику понятен контекст, и он даже может изменить положение ссылки в тексте.
Как такие проблемы решают на тех же десктопных гуях
Делаются отдельные от текста
В HTML5 charset задаётся иначе.
<meta charset="UTF-8">
Я сталкивался при локализации с тем, что многие коммерческие либы не работают в режиме «пишем справа налево».
Из-за чего языки вроде Арабского и Иврита очень сложно поддержать.
Из-за чего языки вроде Арабского и Иврита очень сложно поддержать.
В PHP для Вордпресса вместо
echo(__('Username', 'my-plugin'))можно написать покороче:
_e('Username', 'my-plugin')Так даже лучше — меньше скобок.
Sign up to leave a comment.
Двенадцать заповедей локализации ПО