На заметку домохозяйке
 

Делать локализацию JS-кода очень просто, если придерживаться простого правила.

для строк которые требуют перевода использовать "двойное кавычки"
для строк которые участвуют только в логике 'одерную кавычку'

а далее дело техники:
в коде выискиваются строки в двойных кавычках и заменяются на перевод.
в коде выискиваются строки в двойных кавычках и оборачиваются в функцию.
в коде выискиваются строки в двойных кавычках и заменяются на переменные.

поиск можно реализовать простой регуляркой

// \/\*([^*]|\*(?=[^\/]))+\*\/|\/(\\\\|\\\/|[^\/\n])+\/|'(\\\\|\\'|[^'])*'|"(\\\\|\\"|[^"])*"

ага объект-словарь для слабаков
[zanuda_mode]Если специальные действия предпринимаются на этапе разработки, то это уже интернационализация[/zanuda_mode]

ручное создание "объект-словарь" это от переизбытка сил.
приведу пример vk.com, там очень сильная команда . и как результат http://vk.com/js/lang3_0.js?3247

Фиг знает, мне разные кавычки мозолят глаза.

Далеко не во всех конторах есть возможность нанимать только спецов программирования. Да и реализация такой тривиальной вещи, как языковый файл, не требует особых умозатрат, только нудный, унылый копипаст. Либо же «программистом» скрипта был сам переводчик.

в зависимости от объемов. сложнее поддерживать актуальным, часто имя переменной уже не соответствует что в ней. сам код становиться сложнее для восприятия. я использую js-шаблоны , эти шаблоны тогда вообще превращаются в не-пойми что.

контролировать тип кавычки нетрудно, это культура кода как и отступы.

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

Теперь же приведу пример решения в продукте с которым имеет дело несколько большее количество программистов - WordPress.
Так в PHP-коде регестрируються переводы

wp_localize_script( $handle, $object_name, $l10n );

$handle - область видимости переменной
$object_name - имя глобальной переменной для объекта-словаря
$l10n - сам объект словарь.
В результате выполнения на страницу инлайново прописывается скрипт с переводами актуальный для текущей страницы.
С учетом того что $l10n принято задавать в виде пар

'savingText' => __('Saving Draft…'),

, мы получаем управление переводами из одного централизованного источника - mo/po файлов, а не ведем две независимых системы переводов для серверной и клиентской части, и уж тем более не думаем над придуманными нами форматами файлов и даже можем за пару минут подготовить po-файл с нехватающими нам переводами на оутсорс переводчику, и у переводчика не возникнет особых проблем с его редактированием

Gvozd,
тут речь о js, а не о php. "Что позволено Юпитеру, то не позволено быку"

Ну вообще-то я о JS и говорю.
Просто управление переводами происходит на серверной стороне, средствами CMS, которые я описал.
И я нахожу удобным, когда CMS берет на себя заботу об управлении еще и таким контентом как переводы сообщений, ага.

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

Gvozd,
распространены два подхода.
1) ваш , когда используются имя константы как ключ к переводу.
xx -> Текст | Text | ...
2) когда в качестве ключа сам текст который нужно переводить.
Текст -> Текст | Text | ...

второй вариант хорош тем что на этапе разработке можно меньше думать о локализации. шаблоны выглядят более человечны чем когда вместо текста какая-та константа с корявым названием. Матрицу перевода можно формировать автоматически. Тот текст для которого еще нет перевода останется без перевода.

Второй подход используется на множестве проектах и не только в вебе. Я лишь указал возможно использования особенности JS , в качестве маркера использовать двойные кавычки.