База
В российском сегменте разработки программного обеспечения исторически сложилось так, что молодой разработчик подспудно считает, что программа написанная по заказу российской компании и для российского пользователя в принципе никогда не попадет в руки кого-нибудь за рубежом. Во многом это связано с предыдущей эпохой, когда связи с остальным миром были сильно нарушены по понятным причинам. Однако даже тогда почему-то считалось, что отечественное программное обеспечение это нечто непременно разговаривающее с пользователем исключительно по-русски. Хотя в то же время партнерами СССР были страны совершенно несвязанные с русской культурой и языком. Это наши некоторые юго-восточные союзники, страны Африки, Куба, Афганистан.
Если даже говорить о, пусть и близких, но все-таки не совсем русскоговорящих, партнерах в восточной Европе и балканских странах, то выяснится, что даже кириллицей пользуются совсем не многие из них. Поэтому лично мне не очень понятно почему ни кто наказывает программистов за принудительную русификацию программ. Ну, хорошо, есть совсем узкий круг задач для закрытых предприятий, решение которых вряд ли пригодится где-нибудь кроме российской федерации. С другой стороны, а как же, например, Белоруссия? Киргизия? Прости Тенгри, Монголия?
А как же в конце концов национальные языки внутри страны? Хорошо, может быть, для внутренней документации, исходной кодировки и форматов дат и чисел достаточно русского языка, но пользовательский интерфейс совершенно не обязан быть только на государственном. Может региональный сайт разговаривать с пользователем на местном языке? Запросто.
В общем локализация программ под определенный язык и алфавит не очень умная идея с самого начала. Другое дело, что должен быть базовый вариант программы. Должны быть базовые конвенции именования внутренних конструкций, моделей. Должен базовый язык документирования и журналирования. Здесь не всё так однозначно, однако очевидно, что так уж сложилось, что языки программирования основаны на английском (за одним двумя исключениями). Может быть если команда разработчиков набралась такая, что у нее большие проблемы с английским. Либо, может быть, это требование заказчика обязательно иметь полностью русифицированную внутреннюю документацию. В общем по ряду (не длинному) причин может оказаться так, что вы намеренно выбираете российскую локаль за основную и главную. Во всех остальных случаях разумнее будет воспользоваться ASCII, английский, в крайнем случае транслитерацию.
Кроме обозначенных факторов для такого выбора есть и другие менее очевидные аргументы. Документировать программы на английском банально проще. Надо еще раз обратить пристальное внимание читателя, что речь идет именно о внутренней документации. Если хорошенько присмотреться к внутренним документам программ, к спецификациям, инструкциям, описаниям, то окажется, что минимум две трети использованных слов окажутся калькой с английского. Окружение, файл, формат, среда выполнения, бек-энд, сайт, спецификация, декларация, строка, консоль, локаль - можете сами легко продолжить этот список, и одной дюжиной вы точно не отделаетесь. Так зачем же всё это переводить на ходу, подыскивать русские аналоги слов, перевода к которым иногда просто еще не придумали?
Второй не самый очевидный аргумент это плейсхолдеры. Тут даже речь не о пользовательском интерфейсе. Если в принципе чему-то и где-то лучше было бы иметь фиксированные размеры, то вы не придумаете универсального варианта. В разных языках длина слов и фраз для обозначения одних и тех же вещей будет отличаться. Отличаться будет даже направление письма. Вы должны оставить вариант, который будет работать хотя бы в одном случае, и это не кириллица и не русский. Журналы, отчеты, имена полей и прочее тому подобное, в латинице будут работать исходно в любом окружении.
Ресурсные файлы и конфигурация
Для встроенных библиотек большинства языков программирования существуют способы изначально сделать программу более или менее готовой к локализации. Но для этого нужно соблюсти ряд общих правил. С непривычки за ними трудно уследить, особенно когда вы до этого совсем над этим не задумывались.
В первую очередь в глаза бросаются просто строки внутри программ записанные с использованием любых символов отличных от первой половины таблицы ASCII. Нечто не поддерживающее юникод нынче найти трудно, но с точки зрения локализации это такой маркер. Если вам зачем-то пришлось использовать символы которых нет в стандартной латинице значит ваша программа нуждается в поддержке локалей. Необязательно это должна быть русская буква или слово. Например, это может быть любой диакритический знак, лигатура евро или рубля, обозначение градуса, удлиненные варианты знака “-”, фигурные двойные кавычки, в общем всё что вы не можете набрать с клавиатуры в стандартной раскладке.
Хардкод литералов это само по себе не очень красиво, но так уж и быть, если не докапываться до мышей, то пусть будут. Однако использование при этом литералов не входящих в латиницу - прямое преступление. Выводите всё в ресурсные файлы, в какие-то конфигурации, значения в базах данных.
Маленький лайфхак. Не всегда на глаз можно определить есть в коде запрещенные символы или нет. Для небольших файлов достаточно переключить в редакторе кодировку с одной на другую и русская “О” быстро себя выдаст. Для файлов покрупнее можно примерно так же поступить с использованием уже diff. Нужно сделать копию файла, перекодировать и сравнить с исходным.
Шаблоны и формы
Второе на что следует обратить внимание это выбор считать шаблоны и формы частью исходного кода или внешними ресурсами. Если ваша программа устроена так, что сама отрисовывает форму или отчет, то это определенно часть кода. Так часто происходит, например, с веб-скриптами. В ваш код запросто может быть вшит HTML. Это тоже нынче считается антипаттерном, но деваться от легаси некуда.
Есть и более мягкий вариант такой ситуации. Это когда вроде бы разметка выведена в отдельные файлы, но ваша программа просто не предусматривает переопределения этих файлов во время выполнения или хотя бы с помощью каких-то внешних настроек. Возможность переписать файл шаблона отчета или разметки формы не является решением - ваша программа не поддерживает динамическую локализацию. В таком случае всё сказанное о литералах касается и таких внешних файлов. Если ваша программа не умеет на лету менять саму форму или шаблон, она должна уметь подставлять в шаблон локализованные литералы.
В идеале программа должна понять в каком окружении она запущена и в зависимости от текущей или указанной локали выбирать набор соответствующих файлов. Включая форматы дат, чисел и того же направления письма. Последнее вряд ли получится исхитриться выполнить в виде одного универсального шаблона. Скорее всего вы затратите на это больше сил и времени, чем сделаете несколько копий.
Сообщения об ошибках
Тексты сообщений об ошибках это отдельная боль. Здесь можно и нынче увидеть зоопарк разнообразных изысков. Пишут что попало и как попало. В начале пути часто можно наблюдать отсутствие любой обработки ошибок. Просто вываливаем всё пользователю: и стек, и дамп, и даже явки и пароли. Не говоря уже о языке на котором это делается.
Почему-то принято думать, что тексты ошибок это немного в сторону от пользовательского интерфейса. И если даже есть понимание, что это его неотъемлемая часть, то почему-то считается какой-то отельной. И можно вернуться к ней как-нибудь потом.
На самом деле, конечно же, раз мы говорим о пользователях, то и ошибки должны быть точно так же локализованы и следовать всем правилам. Да, есть класс сообщений, нужных в качестве информации для обратной связи. Но такая информация должна идти как дополнение, а не как первичное сообщение.
Проблема тут заключается еще и в том, что заказчик мало понимает важность спецификации таких деталей. Заказчик часто ограничивается описанием лишь нормального поведения программы. Реакция программы в непредусмотренных ситуациях остается так же непредусмотренной. Программисты же со своей стороны не очень понимают что ошибки выдаваемые бек-эндом и фронтальной частью это не одно и то же. Нельзя просто взять сообщение от сервера и передать его пользователю. Просто потому что бек-энд скорее всего просто не знает о локали фронта. Ну или надо её каждый раз передавать явно.
В правильном исполнении пользовательское приложение должно уметь локализовать сообщения само. Проще всего это сделать на основе цифровых кодов их спецификации. Существуют более сложные ситуации, когда, например, нужно при этом включать в сообщение кроме кода некоторую информацию типа идентификатора события или каких-то количественных показателей. В любом случае содержание ответной реакции должно быть описано и задокументировано. И если не переведено, то хотя бы иметь внешнее описание на языке пользователя.
Журналы
Примерно такая же ситуация, как и с текстами ошибок, может встречаться и с журналами. Тут важно понимать для кого предназначен журнал или конкретное сообщение. Очень часто разработчики пишут журналы для себя. Рассматривая его как источник отладочной информации. На деле же потом в этот журнал приходится заглядывать если не конечным пользователям, то персоналу технической поддержки продукта. Которая не так хорошо осведомлена о стандартных кодах ошибок протоколов или о других технических терминах, во-первых. Во-вторых, опять же, сотрудник сопровождающий систему может читать на отличном от английского языке.
Локализация журнала разумеется дело совсем уж экзотическое, однако правило касающееся литералов и шаблонов соблюдаться должно. Если журнал у вас пишет клиентское приложение и он предназначен для чтения пользователем, то наверное, логично было бы вести его на том же языке. Если же это журнал для технического персонала или для автоматической обработки, то соответственно там наоборот не должно быть никаких слов, которые нельзя разобрать из консоли. Исключение из правил дамп данных. Тут уж никуда не деться. Но значения обязательно должны каким-то образом выделяться, возможно даже с указанием на конкретную кодировку.
Форматы дат и чисел в журналах следует вести строго по международным стандартам, никаких имен месяцев и пробелов в разрядах.
Комментарии
Еще более не очевидно для отечественного разработчика то, что комментарии внутри кода он пишет для других людей, а не для себя в будущем. Даже переводя в латынь тексты комментариев, отечественные программисты брезгуют необходимостью правильно составлять предложения и следить за грамматикой. Часто написанное просто нельзя понять.
Если у вас есть проблемы с временами и идиомами на английском просто не используйте их. Если даже проблем нет, не используйте времена и идиомы. Комментарии в коде это не место для упражнений в прозе или поэзии. Если уж совсем никак с языками просто хотя бы пишите на транслите. Вас должно быть хоть как-то понятно. Главное правило: не понятный комментарий хуже, чем его отсутствие.
А вообще очень плохо, когда у человека проблемы с английским на базовом уровне. Если вы не можете по-английски расписать в исходнике зачем вы использовали в коде какой-то счетчик или с какой целью поставили заглушку, то и программист из вас сомнительный. Почему? Да потому что классы, переменные и методы у вас будут называться так же.
Именование сущностей
Проблема локализации действует в обе стороны. С одной стороны вы должны придумывать правильный перевод для полей и сообщений. С другой - вам нужно правильно придумать аналоги для внутренних сущностей вашей программы. Иначе её никто не сможет прочитать. Причем даже тот кто говорит с вами на одном языке. Транслитерация тут не поможет. Вам все равно надо придумывать короткие и лаконичные имена, например, для таблиц и полей в базе данных. В итоге, то что вы имели в виду под kol или pole не поймете даже вы сами через какое-то время. Что уж говорить о свалке методов типа execAction или processData.
Особенно печально выглядят базы данных при таком уровне локализации. Вам придется дважды описывать что вы зашифровали под тем или иным именем. Сперва в самой структуре данных, затем и в обвязке, которая использует эти имена. Таким образом всегда гораздо проще, хоть и с мелкими ошибками, поименовать метаданные на корректном английском языке. За IsExist или Opened вам руки не оторвут, а вот за Status1 и Status2 поплатитесь сперва вы сами, а затем десять ваших коллег.
Итого
Если прямо не сказано иначе, если нет какого-то регулирующего документа в организации начинайте писать программу изначально на английском. Внутренние спецификации интерфейсов ни кто кроме программистов не читает - тоже полностью на английском. Журналы, если они не для глаз пользователя - на английском, с заранее оговоренными кодами событий. Эти же коды событий можете смело отправлять фронтальному приложению, оно само должно разобраться что выводить пользователю.
Программа должна понимать в какой локали она запущена. Желательно, что бы программа принимала внешний параметр меняющий локаль. В зависимости от локали программа должна уметь подгружать соответствующие ресурсы, шаблоны и формы. В исходном коде, к коему относится и DDL SQL, не должно быть ни единого символа за пределами стандартной латыни. Не фиксируйте форматы чисел и дат. Всегда тестируйте программу в двух и более локалях.
И бесконечно гуглите переводы слов. Это полезно как и в профессии, так и просто в жизни. Гуглить слова тоже надо правильно - в контексте предложений, а не буквально. Не используйте времена и идиомы если без них можно обойтись. Не используйте сленг, отсылки к культурному контексту. Избегайте прямых калек и транслитерации.
Good luck!
*/
End.