Английский язык ГБ, или английский язык США?



Если у вас есть API, и вы являетесь британским разработчиком с высокой международной аудиторией, должен ли ваш API быть

setColour()

или

setColor()

(взять одно слово в качестве простого примера.)

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

Я думаю, вопрос в том, имеет ли это значение? Борются ли разработчики в других локалях с GB орфографией, или это обычно совершенно очевидно, что означают вещи?

Должно ли все это быть американско-английским?

160   28  

28 ответов:

Я бы хотел использовать US-English, поскольку это стало нормой в других API. Говоря как английский программист, у меня нет никаких проблем с использованием "цвета", например.

Я не носитель языка. В письменной форме, я всегда стараюсь использовать en-gb. Однако в программировании я всегда использую en-us вместо британского английского по той же причине, что я не использую немецкий или французский для своих идентификаторов.

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

вообще я был бы сторонником написания GB, но я думаю, что код читается намного лучше, если он согласован, и я нахожу:

Color lineColor = Color.Red;

выглядеть намного лучше, чем:

Color lineColour = Color.Red;

Я думаю, что в конечном счете это не имеет значения.

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

предполагая, что это Java или C# API, это, вероятно, не имеет значения, учитывая распространенность функции автозаполнения в IDE. Если это для динамического языка или того, где современные IDE не являются нормой, я бы пошел с американским написанием. Конечно, я американец и поэтому явно предвзят, но похоже, что большинство кода, который я вижу от разработчиков, которые не являются носителями английского языка, используют американское написание для своих имен переменных и т. д.

как английский программист, я использую en-US для моего программного обеспечения dev. Американский английский настолько хорошо доминирует почти во всех других API, что гораздо проще придерживаться одного типа орфографии и устранить двусмысленность. Это пустая трата времени на поиск метода только для того, чтобы найти орфографию на одну букву из-за локализации орфографии.

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

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

Label myLabel.color = setColour();

У меня есть проблемы с API, которые не находятся в US-English. Просто из-за орфографических различий. Я знаю, что означают эти слова, но другое написание сбивает меня с толку.

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

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

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

Я получил еще один образец: сериализация и сериализация. :)

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

как канадец, я сталкиваюсь с этим все время. Мне очень трудно набрать "цвет", так как моя мышечная память продолжает тянуться к "u".

тем не менее, я склонен принимать язык библиотек. Java имеет класс Color, поэтому я использую цвет.

Я пытаюсь найти альтернативные слова, если это возможно. Я позволю Изе скользить. Для цвета я мог бы использовать оттенок, чернила, передний план/фон...

Если нет, как англичанин, я буду использовать en-GB, потому что у меня есть некоторая гордость в моей стране и происхождении.

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

Мне также придется встать на сторону US-English, просто чтобы держать вещи последовательными (как уже отмечали здесь другие). Хотя я являюсь носителем английского языка в США, я делал программные проекты как с немецкими, так и со шведскими программными компаниями, и в обоих случаях у моих товарищей по команде иногда возникало искушение использовать немецкий или шведский текст в коде-обычно для комментариев, но иногда и для имен переменных или методов. Даже если я могу говорить на этих языках, это действительно сотрясение глаз и затрудняет привлечение нового не говорящего в проект.

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

тем не менее, различие здесь заключается в двух разных диалектах Английский, который не так экстремален, как видеть два совершенно разных языка в одном файле исходного кода. Поэтому я бы сказал, держите API в US-English, но ваши комментарии в GB-English, если вам это подходит лучше.

Я бы сказал, Посмотрите, как другие библиотеки на вашем языке выбирают и следуют их конвенции.

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

Я использую языки .NET в первую очередь, и .NET Framework использует американское английское правописание. На этой платформе я бы остался с нами, англичанами. Я не знаю ни одного языка, стандартизированного на английском языке GB, но если ваш сделал это, то во что бы то ни стало оставайтесь в соответствии с языком.

Я согласен с труппой "go for American". Я сам предпочитаю en-GB при написании электронных писем и т. д., Но американский английский язык в значительной степени является стандартом во всех кругах программирования.

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

определенно американский английский.

во-первых, я в США. В моем текущем проекте это всегда "цвет", однако слово, которое мы не можем выбрать для написания, - "серый" против "серого".

Это на самом деле немного раздражает.

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

мое личное мнение по этому вопросу, однако, состояло бы в том, чтобы предоставить оба написания, дать им setColor() и setColour (), написать код в одном из них и просто передать второй параметр.

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

выбор языка для имен идентификаторов не имеет ничего общего с аудиторией и все, что связано с языком оригинала, на котором был разработан фреймворк или API.

Я не знаю очень много языков, но я не могу придумать ни одного, который использует что-либо, кроме английского языка США.

опасности введения тонких ошибок из-за различных вариантов написания слишком велики IMHO.

переопределение функции может легко стать псевдо-перегрузка.

файл config может стать недействительным из-за разницы в написании.

может возникнуть ситуация, когда один и тот же концептуальный объект был определен с использованием нескольких классов, используя как en-US, так и en-GB.

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

Если все ваши программисты британцы, используйте en-gb. Если ваш код будет замечен программистами за пределами Великобритании, то en-us будет лучшим выбором.

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

вы должны рассмотреть вашу аудиторию. Кто будет использовать код и что они ожидали увидеть?

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

некоторые вещи пересекают границы, но разница в написании редко является проблемой. Это остро может генерировать некоторые интересные диалоги, когда Американцы не знают о различных написаниях для Кандийского и британского английского языков. Иногда они в порядке с ним, в других случаях они настаивают на его изменении на "правильное" написание. Это также влияет на форматы дат (dd/mm/yyyy в Канаде и mm/dd/yyyy в США)

когда есть тупик, мы обычно идем с орфографией США, так как люди в Канаде знакомы с обоими вариантами.

основная причина, по которой я слышал, что мы выбираем английский язык в Великобритании, заключается в том, что британская аудитория, столкнувшись с орфографией США, понимает, что это приложение США (или предполагает, что это так), тогда как аудитория США, столкнувшаяся с британским правописанием, думает"... Эй, это неправильно.. это цвет, а не цвет'

но, как говорили другие, стандартизируйте. Возьмите и придерживайтесь его.

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

Я предпочитаю американский английский.

Если вы оглянетесь назад на несколько сотен лет, вы обнаружите, что изменения не имеют ничего общего с США, как многие думают. Изменения происходят от европейских влияний, особенно французских. До этого времени английское слово "цвет" было тогда фактически написано "цвет".

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

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

Я всегда использую en-GB для всего моего программирования. Я думаю, это связано с сильным влиянием английских романов.

однако, возможно ли иметь два разных набора API (один для en-US, один для en-GB), которые внутренне вызывают одну и ту же функцию? Это может раздуть заголовочные файлы, хотя, возможно, в зависимости от определения препроцессора, условная компиляция? Если вы используете C++, вы можете сделать что-то вроде ниже...

#ifdef ENGB
     typedef struct Colour
     {
      //blahblahblah
     };
     void SetColour(Colour c);
#else
    typedef struct Color
    {
      //blahblahblah
    };
    void SetColor(Color c);
#endif

в зависимости от того, клиентский программист определяет ENGB или нет, как показано ниже

#define ENGB

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

    Ничего не найдено.

Добавить ответ:
Отменить.