Код “интернационализация”

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

Самая важная причина для этого - возможность поделиться своими проблемами и решениями со всем миром (как мы делаем сейчас в StackOverflow, не меньше) без необходимости переводить имена классов, сообщения об ошибках, пути и другие артефакты каждый раз.

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

Английский код также упрощает добавление иностранцев в проект, не беспокоясь о непонимании и недопонимании ( особенно между близкородственными языками, такими как испанский и португальский, у которых много ложных родственных слов)

Хорошая ссылка на эту тему: http://www.codinghorror.com/blog/2009/03/the-ugly-american-programmer.html

(На всякий случай, я южноамериканец, и английский не мой основной язык)

Обычно код, относящийся к языковым концепциям, должен быть на том же родном языке, что и язык программирования (т. Е. Английский - ведь строка - это все английские слова).

Это нормально (но не здорово) иметь переменные и концепции предметной области на местном языке, но вы определенно не хотите переводить List, Object, Decimal и т. Д. В термины, которые заставят программистов больше работать над согласованием двух языков. . Тем не менее, я бы настоятельно лоббировал ограничение очень распространенных концепций домена, таких как Коллекция, Членство, Человек, Пользователь, и, возможно, менее распространенных концепций домена, таких как Счет-фактура, Квитанция, на английском языке, где это возможно.

Это было бы похоже на кодирование половины ваших классов на VB и половины на C # - ваш мозг должен произвести когнитивный сдвиг. Хотя это хорошо для гибридных приложений (JavaScript в Интернете и C # на бэкэнде), потому что помогает держать то, что работает, где угодно, но не подходит для общего программирования.

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

Всегда есть исключения. Есть определенные случаи, когда вы все равно используете родное слово - где это слово лучше всего описывает сферу. Например, в нашей (английской) кодовой базе у нас были ссылки на мексиканские испанские термины для обозначения определенных понятий, которые имели отношение только к людям, запускающим наше программное обеспечение в Мексике. Обычно японские термины записывались фонетически / ромадзи - неяпонцам было трудно произносить пиктограммы ;-).

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

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

Комментарии и документация по коду на английском языке.

При разработке программного обеспечения с нуля я бы попытался найти английские термины для всех названий методов и даже бизнес-терминов (если это разумно. Я с трудом могу вспомнить пример, в котором термин не может быть найден), чтобы сохранить его " портативный ».

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

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

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

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

Подводя итог, я считаю, что интернационализация кода - плохая идея. Вы можете себе представить, что ключевые слова в языках программирования (например, class, try, while) также могут быть локализованы, и, возможно, вы также можете представить, насколько тяжелой может быть тогда жизнь ...

Даже если все в команде хорошо говорят по-английски (что не является данностью), они не обязательно знают английский эквивалент всей деловой терминологии.

Я думаю, что решение о том, что разрешить, зависит от конкретного проекта, но я обычно терплю и в некоторых случаях поощряю бизнес-термины (например, названия организаций) на местном языке, но не технические термины (т.е. не Largeur / Hauteur вместо Width /Рост).

Например, в финансовом мире во Франции все знают, что имеется в виду под OPCVM и FCP - если вы попытаетесь перевести на английский язык, вы можете столкнуться с большим количеством недоразумений, чем при разрешении смешанных языков.

Если вы пишете код, который однажды может быть использован на международном уровне, пишите его на английском. Если сомневаетесь, пишите его на английском, даже комментарии, если можете (хотя я полагаю, что вы можете добавить несколько комментариев на языке вашего рабочего места).

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

Это может быть печально, если вам хочется защищать свой язык любой ценой, но вы должны быть реалистами в этом вопросе. Я полагаю, что английский язык имеет преимущество в том, что он относительно прост для достижения базового уровня: нет родов для имен, нет спряжений, нет падежей.

Для единообразия я бы сделал код на том же (человеческом) языке, что и язык (программирования). То есть, если в языке программирования используются ключевые слова на английском языке (например, для , switch , public и т. Д.), Оставьте остальную часть кода на английском языке. Если вы используете компилятор, который распознает (скажем) перевод ключевых слов на суахили, оставьте остальную часть кода на суахили.

Многие API имеют стандартизованные схемы именования, которые соблюдаются независимо от (человеческого) языка, а сопроводительная документация переводится по мере необходимости (вместо исходного кода).

Неважно, какой (человеческий) язык вы выберете, выберите один и придерживайтесь его. Я бы скорее попытался пробиться через исходный код на немецком языке, чем код, представляющий собой смесь немецкого и английского языков.

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