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

Question

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

Set LargeurEtHauteur () (для SetWidthAndHeight, fr )
Dim _ListaDeObiecte как список (объекта) (для _ObjectList, ro )
внутренняя пустота Сохранение Пользователь ов () (для SaveUsers, ru )
и т.д.

Бывает, что в странах с латинским алфавитом это сочетание более выражено, потому что нет необходимости транслитерации.

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

Существуют также проекты, над которыми работает только, скажем, французская команда, использующая французские слова (скажем, Personne, АВТОМОБИЛЬ, Projet и т. Д.).

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

Скажите:

Collectif - ансамбль Персоны ;

Все действия (Получить, Установить, Обновить, Изменить, Загрузить и т. Д.) Выполняются на английском языке.

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

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

_{PS.
Меня позабавило, что VisualStudio компилирует и запускает проекты в .NET с кнопками с именем «btnAdd É l è ve» или «кпкСтоп» ...}

Answer 1

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

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

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

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

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

(Если кому-то интересно, я житель Южной Америки, а английский - не мойосновной язык)

Answer 2

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

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

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

Answer 3

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

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

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

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

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

Answer 4

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

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

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

Answer 5

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

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

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

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

Answer 6

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

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

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

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

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

Answer 7

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

Answer 8

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

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

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