JavaScript и поддержка языков. Требуется помощь зала.

[shprota]

История такая. Пишем расширение для J1.5, с языковыми файлами, все как положено.
Имеем несколько не очень маленьких JavaScript файлов, в которых есть текстовые константы, которые бы нехило переводить.
Как лучше реализовать локализацию?
На сегодняшний день не придумал ничего лучшего, чем создавать такой вот php-файл, который генерит яваскрипт:

Код:

<script language="JavaScript" type="text/javascript">
var JLang = [];
JLang['Add'] = '<?=JText::_('Add')?>';
JLang['Add new category'] = '<?=JText::_('Add new category')?>';
JLang['Add related product failed'] = '<?=JText::_('Add related product failed')?>';
....
JLang['Warning'] = '<?=JText::_('Warning')?>';
  function JText(text)
  {
if(JLang[text])return JLang[text];
return text;
  }
</script>

Но это, по-моему, коряво.
Какие будут мнения?

[smart]

Ну как вариант генерить их не на лету, а единоразово, возможно в процессе установки. Вон, в визуальных редакторах часто, локализация в отдельно подключаемых js лежат.

p.s. мелкое замечание по коду - не используй коротких тегов (<?= ) это может быть причиной кучи глюков на серверах, где это выключено.

[shprota]

Ну как вариант генерить их не на лету, а единоразово, возможно в процессе установки. Вон, в визуальных редакторах часто, локализация в отдельно подключаемых js лежат.

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

p.s. мелкое замечание по коду - не используй коротких тегов (<?= ) это может быть причиной кучи глюков на серверах,
где это выключено.

Не встречал таких серверов покамест. Знаю, что это дело можно выключить, но не знаю, нафига его выключать. Да и в локальных настройках ПХП все включается обратно одной строчкой в .htaccess за милую душу.
А шаблоны с таким кодом выглядят куда приятнее чем с кодом типа <?php echo $morzh->hren(2); ?>

[smart]

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

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

Использование коротких тегов это моветон. Ну мое дело посоветовать, а ваше - прислушаться или проигнорировать. Между прочим, об этом изначально предупреждают в описании данного параметра:

; Allow the <? tag.  Otherwise, only <?php and <script> tags are recognized.
; NOTE: Using short tags should be avoided when developing applications or
; libraries that are meant for redistribution, or deployment on PHP
; servers which are not under your control, because short tags may not
; be supported on the target server. For portable, redistributable code,
; be sure not to use short tags.
short_open_tag = On

Так что конечно можно принимать позицию - это не проблема, можно включить и т.д. Но это по меньшей мере неуважение к потенциальным пользователям.

p.s. К слову сказать, за последние полгода я видел штук 9 серверов, где этот параметр по умолчанию выключен.

[shprota]

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

В Джумле 1.5 очень удобно сделана поддержка языков. Централизовано сделана. Потому и хочется не плодить сущностей, чтобы всегда знать, где искать перевод.
А визуальные редакторы - они ведь изначально универсальные, а не специализированные для Джумлы.

Использование коротких тегов это моветон. Ну мое дело посоветовать, а ваше - прислушаться или проигнорировать. Между прочим, об этом изначально предупреждают в описании данного параметра:

В принципе, спорить особо не о чем. Всегда можно просто прогнать компонент через простенькую команду sed