База
В российском сегменте разработки программного обеспечения исторически сложилось так, что молодой разработчик подспудно считает, что программа написанная по заказу российской компании и для российского пользователя в принципе никогда не попадет в руки кого-нибудь за рубежом. Во многом это связано с предыдущей эпохой, когда связи с остальным миром были сильно нарушены по понятным причинам. Однако даже тогда почему-то считалось, что отечественное программное обеспечение это нечто непременно разговаривающее с пользователем исключительно по-русски. Хотя в то же время партнерами СССР были страны совершенно несвязанные с русской культурой и языком. Это наши некоторые юго-восточные союзники, страны Африки, Куба, Афганистан.
Если даже говорить о, пусть и близких, но все-таки не совсем русскоговорящих, партнерах в восточной Европе и балканских странах, то выяснится, что даже кириллицей пользуются совсем не многие из них. Поэтому лично мне не очень понятно почему ни кто наказывает программистов за принудительную русификацию программ. Ну, хорошо, есть совсем узкий круг задач для закрытых предприятий, решение которых вряд ли пригодится где-нибудь кроме российской федерации. С другой стороны, а как же, например, Белоруссия? Киргизия? Прости Тенгри, Монголия?
А как же в конце концов национальные языки внутри страны? Хорошо, может быть, для внутренней документации, исходной кодировки и форматов дат и чисел достаточно русского языка, но пользовательский интерфейс совершенно не обязан быть только на государственном. Может региональный сайт разговаривать с пользователем на местном языке? Запросто.
В общем локализация программ под определенный язык и алфавит не очень умная идея с самого начала. Другое дело, что должен быть базовый вариант программы. Должны быть базовые конвенции именования внутренних конструкций, моделей. Должен базовый язык документирования и журналирования. Здесь не всё так однозначно, однако очевидно, что так уж сложилось, что языки программирования основаны на английском (за одним двумя исключениями). Может быть если команда разработчиков набралась такая, что у нее большие проблемы с английским. Либо, может быть, это требование заказчика обязательно иметь полностью русифицированную внутреннюю документацию. В общем по ряду (не длинному) причин может оказаться так, что вы намеренно выбираете российскую локаль за основную и главную. Во всех остальных случаях разумнее будет воспользоваться ASCII, английский, в крайнем случае транслитерацию.
Кроме обозначенных факторов для такого выбора есть и другие менее очевидные аргументы. Документировать программы на английском банально проще. Надо еще раз обратить пристальное внимание читателя, что речь идет именно о внутренней документации. Если хорошенько присмотреться к внутренним документам программ, к спецификациям, инструкциям, описаниям, то окажется, что минимум две трети использованных слов окажутся калькой с английского. Окружение, файл, формат, среда выполнения, бек-энд, сайт, спецификация, декларация, строка, консоль, локаль - можете сами легко продолжить этот список, и одной дюжиной вы точно не отделаетесь. Так зачем же всё это переводить на ходу, подыскивать русские аналоги слов, перевода к которым иногда просто еще не придумали?
Второй не самый очевидный аргумент это плейсхолдеры. Тут даже речь не о пользовательском интерфейсе. Если в принципе чему-то и где-то лучше было бы иметь фиксированные размеры, то вы не придумаете универсального варианта. В разных языках длина слов и фраз для обозначения одних и тех же вещей будет отличаться. Отличаться будет даже направление письма. Вы должны оставить вариант, который будет работать хотя бы в одном случае, и это не кириллица и не русский. Журналы, отчеты, имена полей и прочее тому подобное, в латинице будут работать исходно в любом окружении.
Ресурсные файлы и конфигурация
Для встроенных библиотек большинства языков программирования существуют способы изначально сделать программу более или менее готовой к локализации. Но для этого нужно соблюсти ряд общих правил. С непривычки за ними трудно уследить, особенно когда вы до этого совсем над этим не задумывались.
В первую очередь в глаза бросаются просто строки внутри программ записанные с использованием любых символов отличных от первой половины таблицы ASCII. Нечто не поддерживающее юникод нынче найти трудно, но с точки зрения локализации это такой маркер. Если вам зачем-то пришлось использовать символы которых нет в стандартной латинице значит ваша программа нуждается в поддержке локалей. Необязательно это должна быть русская буква или слово. Например, это может быть любой диакритический знак, лигатура евро или рубля, обозначение градуса, удлиненные варианты знака “-”, фигурные двойные кавычки, в общем всё что вы не можете набрать с клавиатуры в стандартной раскладке.
Хардкод литералов это само по себе не очень красиво, но так уж и быть, если не докапываться до мышей, то пусть будут. Однако использование при этом литералов не входящих в латиницу - прямое преступление. Выводите всё в ресурсные файлы, в какие-то конфигурации, значения в базах данных.
Маленький лайфхак. Не всегда на глаз можно определить есть в коде запрещенные символы или нет. Для небольших файлов достаточно переключить в редакторе кодировку с одной на другую и русская “О” быстро себя выдаст. Для файлов покрупнее можно примерно так же поступить с использованием уже diff. Нужно сделать копию файла, перекодировать и сравнить с исходным.
Шаблоны и формы
Второе на что следует обратить внимание это выбор считать шаблоны и формы частью исходного кода или внешними ресурсами. Если ваша программа устроена так, что сама отрисовывает форму или отчет, то это определенно часть кода. Так часто происходит, например, с веб-скриптами. В ваш код запросто может быть вшит HTML. Это тоже нынче считается антипаттерном, но деваться от легаси некуда.
Есть и более мягкий вариант такой ситуации. Это когда вроде бы разметка выведена в отдельные файлы, но ваша программа просто не предусматривает переопределения этих файлов во время выполнения или хотя бы с помощью каких-то внешних настроек. Возможность переписать файл шаблона отчета или разметки формы не является решением - ваша программа не поддерживает динамическую локализацию. В таком случае всё сказанное о литералах касается и таких внешних файлов. Если ваша программа не умеет на лету менять саму форму или шаблон, она должна уметь подставлять в шаблон локализованные литералы.
В идеале программа должна понять в каком окружении она запущена и в зависимости от текущей или указанной локали выбирать набор соответствующих файлов. Включая форматы дат, чисел и того же направления письма. Последнее вряд ли получится исхитриться выполнить в виде одного универсального шаблона. Скорее всего вы затратите на это больше сил и времени, чем сделаете несколько копий.
Сообщения об ошибках
Тексты сообщений об ошибках это отдельная боль. Здесь можно и нынче увидеть зоопарк разнообразных изысков. Пишут что попало и как попало. В начале пути часто можно наблюдать отсутствие любой обработки ошибок. Просто вываливаем всё пользователю: и стек, и дамп, и даже явки и пароли. Не говоря уже о языке на котором это делается.
Почему-то принято думать, что тексты ошибок это немного в сторону от пользовательского интерфейса. И если даже есть понимание, что это его неотъемлемая часть, то почему-то считается какой-то отельной. И можно вернуться к ней как-нибудь потом.
На самом деле, конечно же, раз мы говорим о пользователях, то и ошибки должны быть точно так же локализованы и следовать всем правилам. Да, есть класс сообщений, нужных в качестве информации для обратной связи. Но такая информация должна идти как дополнение, а не как первичное сообщение.
Проблема тут заключается еще и в том, что заказчик мало понимает важность спецификации таких деталей. Заказчик часто ограничивается описанием лишь нормального поведения программы. Реакция программы в непредусмотренных ситуациях остается так же непредусмотренной. Программисты же со своей стороны не очень понимают что ошибки выдаваемые бек-эндом и фронтальной частью это не одно и то же. Нельзя просто взять сообщение от сервера и передать его пользователю. Просто потому что бек-энд скорее всего просто не знает о локали фронта. Ну или надо её каждый раз передавать явно.
В правильном исполнении пользовательское приложение должно уметь локализовать сообщения само. Проще всего это сделать на основе цифровых кодов их спецификации. Существуют более сложные ситуации, когда, например, нужно при этом включать в сообщение кроме кода некоторую информацию типа идентификатора события или каких-то количественных показателей. В любом случае содержание ответной реакции должно быть описано и задокументировано. И если не переведено, то хотя бы иметь внешнее описание на языке пользователя.
Журналы
Примерно такая же ситуация, как и с текстами ошибок, может встречаться и с журналами. Тут важно понимать для кого предназначен журнал или конкретное сообщение. Очень часто разработчики пишут журналы для себя. Рассматривая его как источник отладочной информации. На деле же потом в этот журнал приходится заглядывать если не конечным пользователям, то персоналу технической поддержки продукта. Которая не так хорошо осведомлена о стандартных кодах ошибок протоколов или о других технических терминах, во-первых. Во-вторых, опять же, сотрудник сопровождающий систему может читать на отличном от английского языке.
Локализация журнала разумеется дело совсем уж экзотическое, однако правило касающееся литералов и шаблонов соблюдаться должно. Если журнал у вас пишет клиентское приложение и он предназначен для чтения пользователем, то наверное, логично было бы вести его на том же языке. Если же это журнал для технического персонала или для автоматической обработки, то соответственно там наоборот не должно быть никаких слов, которые нельзя разобрать из консоли. Исключение из правил дамп данных. Тут уж никуда не деться. Но значения обязательно должны каким-то образом выделяться, возможно даже с указанием на конкретную кодировку.
Форматы дат и чисел в журналах следует вести строго по международным стандартам, никаких имен месяцев и пробелов в разрядах.
Комментарии
Еще более не очевидно для отечественного разработчика то, что комментарии внутри кода он пишет для других людей, а не для себя в будущем. Даже переводя в латынь тексты комментариев, отечественные программисты брезгуют необходимостью правильно составлять предложения и следить за грамматикой. Часто написанное просто нельзя понять.
Если у вас есть проблемы с временами и идиомами на английском просто не используйте их. Если даже проблем нет, не используйте времена и идиомы. Комментарии в коде это не место для упражнений в прозе или поэзии. Если уж совсем никак с языками просто хотя бы пишите на транслите. Вас должно быть хоть как-то понятно. Главное правило: не понятный комментарий хуже, чем его отсутствие.
А вообще очень плохо, когда у человека проблемы с английским на базовом уровне. Если вы не можете по-английски расписать в исходнике зачем вы использовали в коде какой-то счетчик или с какой целью поставили заглушку, то и программист из вас сомнительный. Почему? Да потому что классы, переменные и методы у вас будут называться так же.
Именование сущностей
Проблема локализации действует в обе стороны. С одной стороны вы должны придумывать правильный перевод для полей и сообщений. С другой - вам нужно правильно придумать аналоги для внутренних сущностей вашей программы. Иначе её никто не сможет прочитать. Причем даже тот кто говорит с вами на одном языке. Транслитерация тут не поможет. Вам все равно надо придумывать короткие и лаконичные имена, например, для таблиц и полей в базе данных. В итоге, то что вы имели в виду под kol или pole не поймете даже вы сами через какое-то время. Что уж говорить о свалке методов типа execAction или processData.
Особенно печально выглядят базы данных при таком уровне локализации. Вам придется дважды описывать что вы зашифровали под тем или иным именем. Сперва в самой структуре данных, затем и в обвязке, которая использует эти имена. Таким образом всегда гораздо проще, хоть и с мелкими ошибками, поименовать метаданные на корректном английском языке. За IsExist или Opened вам руки не оторвут, а вот за Status1 и Status2 поплатитесь сперва вы сами, а затем десять ваших коллег.
Итого
Если прямо не сказано иначе, если нет какого-то регулирующего документа в организации начинайте писать программу изначально на английском. Внутренние спецификации интерфейсов ни кто кроме программистов не читает - тоже полностью на английском. Журналы, если они не для глаз пользователя - на английском, с заранее оговоренными кодами событий. Эти же коды событий можете смело отправлять фронтальному приложению, оно само должно разобраться что выводить пользователю.
Программа должна понимать в какой локали она запущена. Желательно, что бы программа принимала внешний параметр меняющий локаль. В зависимости от локали программа должна уметь подгружать соответствующие ресурсы, шаблоны и формы. В исходном коде, к коему относится и DDL SQL, не должно быть ни единого символа за пределами стандартной латыни. Не фиксируйте форматы чисел и дат. Всегда тестируйте программу в двух и более локалях.
И бесконечно гуглите переводы слов. Это полезно как и в профессии, так и просто в жизни. Гуглить слова тоже надо правильно - в контексте предложений, а не буквально. Не используйте времена и идиомы если без них можно обойтись. Не используйте сленг, отсылки к культурному контексту. Избегайте прямых калек и транслитерации.
Good luck!
*/
End.
Комментарии (17)
ivanstor
30.07.2023 03:29+3Автор великолепен! И во всем прав. Я, правда, дочитал только до идеи наказывать за "принудительную руссификацию" и дальше читать не стал. Поскольку и так прекрасно. Учитывая сколько имеется на свете языков — программистов можно наказывать непрерывно. А если добавиться всяческие диалекты и местные наречия... М-м-м!.. Лепота.
Предлагаю создать публичные лобные места и сечь их, сечь, сечь...
Или автор имел ввиду только русский? Но и тогда всё неплохо. Взять хоть программистов 1С. Необъятный источник для БДСМ.
shasoftX
30.07.2023 03:29+2А вообще очень плохо, когда у человека проблемы с английским на базовом уровне. Если вы не можете по-английски расписать в исходнике зачем вы использовали в коде какой-то счетчик или с какой целью поставили заглушку, то и программист из вас сомнительный. Почему? Да потому что классы, переменные и методы у вас будут называться так же.
Как бы сильно большая разница между написать название переменной/метода и написать текст, который описывает что метод делает. Тут очень разный уровень английского используется.
Rembo123 Автор
30.07.2023 03:29-1Я бы не согласился с таким утверждением. По причине того, что нынче считается, что если класс и метод названы правильно, то в общем отдельно объяснять смысл и не нужно. А если и нужно, то описать требуется только очень специфические моменты. Ну, например, нынче вполне конвенционально назвать метод
testFunctionThrowsExceptionWhenParameterIsEmptyКакой еще дополнительный уровень знания языка тут нужен? Допустим, надо пояснить, что для PHP '0' не должно рассматриваться как пустое./* Expects '0' is not empty */shasoftX
30.07.2023 03:29+1Ну разве что подразумевается что всё описание работы метода нужно запихивать в название метода. Тогда ДА, уровень знания нужен один и тот же.
Rembo123 Автор
30.07.2023 03:29Если имеется ввиду что надо как-то описать очень сложную внутреннюю логику, то тут кажется, что придется прибегнуть к сложным оборотам. Я понимаю о чем речь. Так часто получается, когда нужно задокументировать старый код. Но опять же по современным канонам, получается так, что это проблема скорее самого метода, значит его можно разложить на куски попроще. Либо техническое задание страдает какими-то изъянами. С другой стороны, раз этот метод уже введен в эксплуатацию и он энное время уже и так работает без документации, то надо ли вообще его документировать сейчас? )
shasoftX
30.07.2023 03:29+2Надо! Потому что зачастую приходится каждый раз заново разбираться как этот метод работает. Не говоря уж о том, что зачастую практика с канонами не дружит. И не потому что разработчик их не знает, а потому что "сделать нужно быстро и желательно ещё вчера". Поэтому вставляется костыль. И простым названием метода/переменной этот костыль зачастую сложно описать. Да ещё на неродном языке.
Hokum
30.07.2023 03:29+1А кто оплачивать поддержку локализации будет, если это не надо заказчику? Это увеличивает объем тестирования, в каких-то случаях будет тратится больше времени на проработку интерфейса, чтобы он выглядел удобным на разных языках. Да и опять же больше вводить текста и не забывать вносить изменения во все языковые ресурсы. А если только предусмотреть возможность смены ресурсов, то сильно проще провести локализацию на другой язык не будет, так как весь интерфейс может или разъехаться или будут пустые огромные пространства. К тому же, для локализации нужен человек которые не просто знает этот язык, а знает его в нужной предметной области, разработчики такими, чаще, не являются. Да и терминологии на родном языке в нужной предметной области могут не знать, чего уж там, но правильный текст будет прописан в задании или на приемке заказчик поправит.
А что касается документации, комментариев и кода. На родном языке читать документацию проще. И в этом плане жаль, что не все компиляторы пропустят не ASCII символы как код. Тут остаётся немного позавидовать тем, кто использует латиницу - они могут и имена сущностям в коде давать на родном для них языке.
Код и внутренняя документация - для тех кто участвует в разработке и сопровождении. И документацию к программе, комментарии к коду и код могу читать не только разработчики, но и команда тестирования, прочие технические специалисты занимающиеся поддержкой и установкой. И им точно удобнее читать на родном языке.
Если есть возможность обеспечить внутри компании поддержку одной локали без снижения производительности всех сотрудников задействованных в разработке, поддержке, сопровождении и эксплуатации - это же прекрасно. Это упрощает коммуникации, упрощает разработку. Удобно же когда житель Германии столкнувшись с ошибкой в программе видит ошибку на немецком, а тестировщик или специалист по сопровождению открыл документацию или код и легко может понять, что происходит, ведь все описано на, родном, немецком языке. Там где поддержка нескольких языков нужна, она есть, но не надо тащить её туда где этого не требуется.
Если говорить о сайтах, то если сайт рассчитан на внутренний рынок, то снова не надо тратиться на поддержку нескольких языков. Это дорого и не даст прибыли. Сайт для разных стран - это не просто перевести весь текс на другой язык, надо так же учитывать культурные особенности. Это и используемые изображения, расположение элементов управления, так же может меняться в зависимости от того откуда пришел пользователь. Это если сайт насчитан на разные страны. А если нет и просто случайный пользователь забрел полюбопытствовать, то браузеры вполне ему помогут переведя текст на удобный ему язык. Далеко не всегда хорошо, но в целом - сносно, найти то за чем пришел можно.
Rembo123 Автор
30.07.2023 03:29Речь не о создании программ которые уже локализованы под все языки. Речь о том что бы просто предусмотреть такую возможность в будущем. Тем более что делается это совершенно просто с помощью соответствующих библиотек. Надо лишь соблюсти ряд вышеописанных условий.
На родном языке читать документацию проще.
Сомнительное заявление. Проще для кого опять же? Я говорю о подходе в принципе. Надо смотреть на мир чуть шире.
Там где поддержка нескольких языков нужна, она есть
А в какой момент у нового проекта наступает нужность добавления других языков? Кто вообще может узнать и заинтересоваться вашей библиотекой или фреймворком зарубежом, если никто просто не может понять что это?
Hokum
30.07.2023 03:29+2Речь о том что бы просто предусмотреть такую возможность в будущем. Тем более что делается это совершенно просто с помощью соответствующих библиотек. Надо лишь соблюсти ряд вышеописанных условий.
Даже просто поддержка разных локалей, без перевода, требует времени - надо переключить локаль и проверить, что даты и числа стали в соотвествии с локалью. А тут еще помнить и проверять, не сломали ли, что весь текст хранится в ресурсах и берется от туда. Это требует времени. Точно так же, как нет смысла без необходимости пытаться поддерживать все платформы. Нужно считать затраты - если они себя могут окупают или могут потенциально купить, тогда поддержка локализаций имеет смысл, если нет - то нет.
Да и в целом поддержка этого и надежда, что это упростит в будущем возможную локализацию даст скорее ложную иллюзию, что это можно сделать просто и быстро. Более того, даже проект который уже имеет локализацию на разные языки может оказаться не готов к другому языку, потому что у него текст справа на лево или сверху вниз, а не слева на право. Или более простое - высота символов, чтобы текст было комфортно читать, выше.
Более того к моменту когда проекту понадобится локализация или он будет выложен в опенсорс, могут пройти годы и за это время он будет не единожды переписан. И время которое якобы съэкономилось на подключение нового языка, если такое сучилось, с лихвой было перекрыто лишними затратами на гипотетическую поддержку.
Сомнительное заявление. Проще для кого опять же? Я говорю о подходе в принципе. Надо смотреть на мир чуть шире.
Для того, кому этот язык родной. В жизни не поверю, что французу или вьетнамцу удобнее читать на английском языке в противовес их родному. Причем тут смотреть на мир шире?
А в какой момент у нового проекта наступает нужность добавления других языков?
Зависит от проекта, может и никогда не наступить.
Кто вообще может узнать и заинтересоваться вашей библиотекой или фреймворком зарубежом, если никто просто не может понять что это?
Это уже не просто что-то написаное по заказу российской компании. Если просто что-то выложить на условный гитхаб, то об этом сам по себе мало кто узнает. Нужно продвигать. Язык(и) используемые для документации будут зависеть от "рынков" продвижения. Для увеличения охвата, в опенсорс проекте, имеет смысл и комментарии писать на английском и переменные называть на нем же, просто тогда охват будет больше.
К тому же продвигать продукт на разные рынки и сделать код и внутреннюю документацию открытыми - это разные вещи. Если код проекта и внутренняя документация закрыты, то всё равно на каком языке там комментарии. Главное, чтобы с пользователем продукт "разговаривал" на нужном языке.
Так что если есть заказчик - то он решает нужна локализация, на каком языке будет вестись разработка, и да вполне может быть, что требование германского заказчика будет то, что вся документация и комментарии к коду должны быть на немецком и плевать откуда команда разработки и на каком языке она говорит. Аналогично и для российской компании.
Ну и опять же, возвращаясь к началу статьи, про программу, которая "написанная по заказу российской компании и для российского пользователя". Если такая программа попала в руки зарубежного пользователя, то он, наверно, понимает, что это и зачем, а если нет, то скорей всего оно ему и не надо.
С некоторой вероятностью, ему может быть полезно что-то выложенное в опенсорс, но тут автор решает, что и как ему удобно. Хочет на русском, хочет на арабском или китайском пишет. Он мог это выложить просто чтобы где-то еще держать свой код, ему так разрабатывать удобнее. Пользователи которые наткнулись на этот проект и которым он помог решить их задачу, могут потратить свое время и предложить локализацию или перевод документации в рамках пул-реквестов.
oldnomad
30.07.2023 03:29+1В жизни не поверю, что французу или вьетнамцу удобнее читать на английском языке в противовес их родному. Причем тут смотреть на мир шире?
Уж поверьте. Мне, при родном русском, на порядок проще любой технический текст и читать, и писать по-английски. Хотя бы уже из-за недостатка терминологической гибкости в русском, где и undefined behavior (нет определения поведения), и undetermined behavior (не определён выбор поведения), оба оказываются "неопределённым поведением".
Hokum
30.07.2023 03:29Можно одинаково перевести, а можно и по-разному: undefined behavior - неопределенное, undetermined behavior - неоднозначное (недоопределённое, неустановленное, неопределяемое) поведение. Но во втором случае скорее поймут, если использовать недетерминированное поведение.
Ну и если тот кто будет читать, то что вы написали плохо знает английский, на уровне школы, то он просто в гугл-транслейте переведет, ваш текст и так же получит в обоих случаях "неопределенное поведение". Так что писать надо так, чтобы было удобно и понятно целевой аудитории. А если пишете только для себя - то пишите так как вам удобно.
oldnomad
30.07.2023 03:29Ну и если тот кто будет читать, то что вы написали плохо знает английский, на уровне школы, то он просто в гугл-транслейте переведет, ваш текст и так же получит в обоих случаях "неопределенное поведение". Так что писать надо так, чтобы было удобно и понятно целевой аудитории.
Тут вы совершенно правы, писать надо для целевой аудитории. И я сильно сомневаюсь, что люди "плохо знающие английский" входят в целевую аудиторию технических текстов. Так же как люди не знающие латынь явно не входили в целевую аудиторию европейских учёных XII века, а люди не знающие древнегреческого -- в целевую аудиторию римских учёных классического периода.
Hokum
30.07.2023 03:29Запросто, особенно учитывая круг компаний, которые автор упоминает - российские компании, для российского пользователя. Причем уровень владения английским будет разным и я не про "писать", а про "читать". Кому-то, как и автору, проще читать и писать на английском, кому-то писать и читать будет легче по-русски. Если уровень всех потенциальных потребителей достаточен для беглого чтения, то да можно и писать, по договоренности. Но это не является какой-то догмой, как считает автор. Ради чего намеренно усложнять и без того сложную вещь как коммуникация? А документация и комментарии к коду - это тоже, своего рода, вид коммуникации между людьми.
В международных компаниях, или тех, что планируют нанимать разработчиков из разных стран, там да, вопрос на каком языке писать документацию и комментарии стоит иначе. Но в полностью местной компании, работающей на местный рынок писать документация на иностранном языке из предположения, что все остальные должны знать этот иностранный язык - странно.
Опять же, документацию и код могут читать не только разработчики и тестировщики, да и в целом начинающие специалисты могут хуже владеть иностранным языком, меньше сталкиваться с литературой на нем, просто потому, что достаточно хороших переводов. Если очень хочется практиковаться в английском, можно внутри компании организовать разговорные клубы.
Ну и в целом, касательно языка - почему тогда существует ресурс habr? Если все технические специалисты предпочитают писать на английском, а в русском недостаточно гибкости и терминов. Точнее, почему тут появляются технические статьи на русском и переводы с английского, и переводы воспринимаются в целом хорошо? Причем и сам автор тут же пишет свои статьи по-русски. Что на мой взгляд, как раз и подтверждает востребованность и документации, и комментариев на русском языке в русскоязычных компаниях.
Если в компании есть не русскоговорящие, то тогда да, стоит использовать другой язык. Но снова, если русскоговорящая команда хорошо знает, например, испанский и английский, а другая часть команды лучше говорит на испанском, чем английском, то лучше для документации выбрать испанский язык.
Rembo123 Автор
30.07.2023 03:29Вы вывели свою трактовку того что написано, а затем пытаетесь её же опровергнуть. Ни кто говорит о том, что надо общаться на иностранном языке. Тезис очень простой - раз вы уже пишите код на языке основанном на английском, то почему бы и его технические атрибуты не писать на английском. И если это делать, то такой продукт будет легко адаптировать сразу на любой другой язык.
Более того, я специально оговорился, что если команда договорилась этого не делать по каким-то причинам - ради бога. Русский так русский как базовый. Опять же это никак не мешает сделать программу локализуемой изначально.
Обоснованным должно быть решение именно сделать программу для конкретного языка и под конкретную страну. А не наоборот.
Hokum
30.07.2023 03:29Обоснованным должно быть решение именно сделать программу для конкретного языка и под конкретную страну. А не наоборот.
Я как раз вот с этим и не согласен. Если нет потребности в данный момент в поддержке локализации, то и не надо её тащить. Появится - тогда и надо добавлять. Потому, что затраты на сопровождения большие и к моменту необходимости локализации проект может быть переписан и не один раз.
И на мой взгляд, есть еще некотор противоречие в том, что для пользователя вы хотите, чтобы был его родной язык, причем не только для пользователя, но и для специалистов технической поддержки продукта с его стороны (внешние по отношению к компании), когда говорите о журнале. Но для самих себя предлагаете писать разработчикам на иностранном языке.
Ну и во внутреннюю документацию так же заглядывают специалисты технической поддержки, чтобы лучше понимать как работает система и чем может быть вызвана та или иная ошибка. Специалисты первой линии, когда к ним приходят с вопросам пользователи. В крупных компаниях, до разработчика коммуникация с пользователем может и не дойти никогда.
ppnn
30.07.2023 03:29+1| Гуглить слова тоже надо правильно - в контексте предложений, а не буквально
context.reverso.net , не благодарите)
anzay911
Серый экспорт.