Что делать с предметно-ориентированными словами и фразами на иностранном языке?

Question

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

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

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

Что вы делаете, и что вы думаете об этом?

Answer 1

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

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

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

Я также работал с некоторыми неродными нидерландскими программистами, и у них не было никаких проблем при работе с голландским эквивалентом getVirksomhet () и т. Д.

Answer 2

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

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

Answer 3

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

Великобритания: английский, конечно.

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

Франция: Ну, французский написан без акцентов. В большинстве случаев это выглядит как инвертированный английский, то есть «getApplicationCourante» вместо «getCurrentApplication». Это имеет приятный побочный эффект: при сортировке по алфавиту методы будут сгруппированы по существительному имени, которое обычно важнее прилагательного. Тем не менее, неизбежное сочетание двух языков выглядит ужасно, но это действительно лучше, чем французы используют английский: -P

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

Answer 4

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