Комментарии 7
Хабрачеловек, если знаешь какие-то хорошие доводы против gettext - пиши!
А вообще, интересно узнать чужой опыт. Или что посоветуете использовать для создания многоязычного интерфейса крупного проекта!
А вообще, интересно узнать чужой опыт. Или что посоветуете использовать для создания многоязычного интерфейса крупного проекта!
0
yandex использует, недавно слушал презентацию их инсайдера по поводу локализации. Даже уверен в том, что и другие также используют. Собственно, а какие альтернативы, если нужна локализация?
Оптимизировать всегда нужно архитектурно, а не локально. Это не тот уровень прироста производительности, что стоит количества проблем, если от него отказываться.
Оптимизировать всегда нужно архитектурно, а не локально. Это не тот уровень прироста производительности, что стоит количества проблем, если от него отказываться.
+2
Стоит, еще как стоит!
Причем, чем масштабнее проект, тем больше доводов в пользу gettext. При здоровом коде очень сильно помогает именование строк их содержанием на выбранном языке - не нужно лезть, смотреть что значит строка с номером N. Плюс Очень просто организовать локализацию на любое количество языков - вопрос только в переводчиках.
Причем, чем масштабнее проект, тем больше доводов в пользу gettext. При здоровом коде очень сильно помогает именование строк их содержанием на выбранном языке - не нужно лезть, смотреть что значит строка с номером N. Плюс Очень просто организовать локализацию на любое количество языков - вопрос только в переводчиках.
0
Пробовал использовать gettext в CMS.
Основной довод против - сложность интеграции редактора переводов с админчастью.
Писать свой web frontend для редактирования .po файлов - изобретать велосипед. Интегрировать существующие в свой проект - сходу не удалось.
Использовать off line редактор в моем случае - нельзя.
Пришлось отказаться от этой идеи.
Основной довод против - сложность интеграции редактора переводов с админчастью.
Писать свой web frontend для редактирования .po файлов - изобретать велосипед. Интегрировать существующие в свой проект - сходу не удалось.
Использовать off line редактор в моем случае - нельзя.
Пришлось отказаться от этой идеи.
0
мне кажется, если не "в вашем случае", то вполне было бы нормально давать возможность переводчику скачивать файл, он у себя поредактил, а потом загрузил обновленный....
(и даже было бы не сложно создать возможность создания новой локализации... но это редко надобится...)
(и даже было бы не сложно создать возможность создания новой локализации... но это редко надобится...)
0
понятие "переводчик" уместно когда речь идет о десктоп системе с локализациями(переводами) языкозависимых констант(кнопки, тексты)
и вряд ли применимо для web проекта где "переводчиков" может быть несколько, и они никак не связаны с разрабочиками системы, а многоязычным должно быть само содержание сайта.
и вряд ли применимо для web проекта где "переводчиков" может быть несколько, и они никак не связаны с разрабочиками системы, а многоязычным должно быть само содержание сайта.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Стоит ли использовать _(gettext) в масштабном проекте?