Используете язык Python или эквивалент в веб-приложениях?

Question

Кажется, что реализация языка Python хочет либо прочитать язык из системных настроек, либо установить его с помощью вызова setlocale. Ни то, ни другое не работает для меня, поскольку я хотел бы использовать возможности в веб-приложении, где желаемым языком является язык пользователя.

И в региональных документах есть предупреждения, которые делают все это страшным:

Кроме того, некоторые реализации сломаны таким образом, что частые изменения локали могут вызвать дамп ядра. Это делает язык несколько болезненным правильно использовать

И

Это вообще плохая идея звонить setlocale () в некоторой библиотечной подпрограмме, поскольку в качестве побочного эффекта это влияет на вся программа

Итак, есть ли разумная альтернатива локали для использования в веб-приложениях? Бабель это или есть другие альтернативы? Я ищу что-то, что будет обрабатывать валюты, а также даты и цифры.

[Обновить] Чтобы уточнить, меня больше всего интересует форматирование даты, числа и валюты для различных локалей.

Answer 1

locale не годится для любого приложения, которое должно поддерживать несколько локалей - оно действительно плохо спроектировано для этих приложений (в основном для любого серверного приложения, включая веб-приложения). Где возможно, PyICU является превосходным решением значительно - высококачественная поддержка i18n / L10n, скорость, гибкость (недостаток: в то время как документы ICU хороши, PyICU, ну, не так уж много) ;-). Увы, не всегда вам разрешено развертывать собственные расширения ...: - (.

В частности, я все еще ищу надежное решение i18n / L10n для приложений App Engine - «перевод» сам по себе является наименьшим количеством проблем (вы можете просто переключиться на правильный набор шаблонов), проблема в том, что есть много других аспектов L10n (те, которые ICU поддерживает так хорошо, например, правила сопоставления и т. д. и т. д.). Я думаю, что уже упомянутый Бабель - единственное разумное место, с которого можно начать.

Answer 2

Не использовать setlocale.

Проверьте, как это делается в Джанго . Похоже, они используют API класса библиотеки gettext и не используют функцию setlocale. Держу пари, что для этого есть причина.

Они вручную сохраняют перевод для потока проверьте здесь как это реализовано (функция gettext и _active Dictionary).

Answer 3

Фреймворк Django i18n устраняет недостатки setlocale(), не используя его. Таким образом, языковой стандарт устанавливается для каждого запроса, и если вы используете LocaleMiddleware, его можно изменить в соответствии с настройкой UserAgent Accept-Language. См. документы .

Answer 4

Ваш лучший подход будет к setlocale в локали, которую пропускает браузер, если вы используете валюты, даты и цифры. В документации по Python есть много предупреждений zomgz для действительно не цветных платформ; большинство из них можно игнорировать.

«Частые изменения локали» не должны иметь значения, если я что-то упустил.

Вы не делаете каталоги сообщений или что-то необычное, поэтому придерживайтесь того, что дает вам Python.