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

Ответ 1

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

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

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

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

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

(В случае, если кто-то задается вопросом, я южноамериканский, а английский не мой основной язык)

Ответ 2

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

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

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

Ответ 3

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

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

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

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

Ответ 4

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

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

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

Ответ 5

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

Это нормально (но не очень), чтобы иметь переменные и понятия домена на локальном языке, но вы определенно не хотите переводить List, Object, Decimal и т.д. в термины, которые заставляют программистов больше работать при согласовании двух языков, Тем не менее, я бы настоятельно рекомендовал ограничить очень общие концепции домена, такие как Collection, Membership, Person, User и, возможно, менее распространенные концепции домена, такие как Invoice, Receipt to English, где это возможно.

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

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

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

Ответ 6

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

Ответ 7

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

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

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

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

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

Ответ 8

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

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

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