Кодекс «интернационализация»

Question

я работал над различными проектами в разных странах, и отметил, что иногда код стал интернационализированы, как

Set LargeurEtHauteur()                                                     (для SetWidthAndHeight, фр)
Dim _ListaDeObiecte в List (Of Object)     (для _ObjectList, ро)
внутренняя пустота Sohranenie Пользователь ом()                         (для SaveUsers, р)
т.д.

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

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

Есть также проекты, на которых работает только, скажем, французская команда, использует французские слова (скажем, Personne, vehicleule, Projet и т. Д.).

В этом случае я лично добавляю в спецификации «Словарь», который объясняет все имена бизнес-объектов, и только эти объекты используются на другом (французском) языке.

Скажи:

Collectif - ансамбль де Personnes;

Все действия (Get, Set, Update, Modify, Load и т. Д.) Находятся на английском языке.

Теперь, когда "сильные" имена могут быть использованы в коде: Добавить Personne Для Collectif.

• Каков ваш подход к «интернационализации»?

_{PS.
Я был удивлен, что VisualStudio компилирует и запускает проекты в .NET с помощью кнопок имени а-ля «btnAdd É л è вя» или «кпкСтоп» ...}

Answer 1

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

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

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

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

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

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

Answer 2

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

Answer 3

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

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

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

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

Answer 4

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

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

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

Answer 5

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

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

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

Answer 6

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

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

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

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

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

Answer 7

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

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

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

Answer 8

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

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

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

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

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