Я понимаю, что большинство языков поддерживают несколько языков, но каждый язык, который я видел, всегда был более или менее ориентированным на США. Под этим я подразумеваю ключевые слова, стандартные библиотечные функции и т.д., Все имеют английские имена. Итак, как программист, вам по-прежнему нужно знать хотя бы какой-то английский, чтобы понять это.
Есть ли на самом деле "многоязычные" языки с поддержкой языковых ключевых слов и т.д. на нескольких языках?
Это, как правило, ужасная идея, о которой может свидетельствовать любой, кто работал в локализованной среде IDE. Программисты в значительной степени полагаются на один общий словарь. Когда компилятор дает мне ошибку "отсутствующий спецификатор типа - int предполагается", я могу поделиться этим точным сообщением об ошибке с другими, например здесь, на SO, и он будет знаком другим, чтобы они могли сказать мне, что это значит. Если компилятор вместо этого генерировал сообщения об ошибках на датском языке, я бы ограничился получением помощи от относительно немногих программистов, которые говорят на датском языке.
Внезапно мой словарный запас уже не тот, кто находится на той же позиции в Германии, Франции или Японии. Мы больше не можем обмениваться кодом, ошибками, ошибками или идеями.
Разработчик в Испании не сможет использовать мой код, потому что он был буквально написан на другом языке. И если бы у меня были проблемы с моим кодом, другие были бы беспомощны, чтобы отлаживать его, потому что он даже не компилировался под их настройками локализации (и если бы это было так, это все равно было бы нечитаемо для них).
В конечном счете, язык программирования - это язык. Возможно, он позаимствовал некоторые слова с английского языка, но это не английский, и вам не нужно понимать английский язык для программирования в нем, не больше, чем мне нужно понимать латинский язык, чтобы говорить по-английски (английский также занимает латинские слова).
Вы также можете попросить многоязычный английский. Какой смысл? Да, это теоретически позволит людям, которые не говорят по-английски,... говорить по-английски. Это просто не было бы таким же английским, как говорит любой другой англоговорящий, поэтому на самом деле он не мог бы общаться между ними.
Ключевое слово if в языке программирования не совпадает с английским языком. Они означают разные вещи, хотя один был явно вдохновлен другим.
Ключевое слово delegate в С# не означает то же, что и "делегат" на английском языке. Также не существует while, return или "конструктор". Это не английские слова, они ключевые слова или понятия в С++, Java, С#, Python или любой другой язык программирования.
Мне кажется плохой идеей. Если я пишу программу, как мне узнать, что имя переменной, которую я набираю, на самом деле является ключевым словом на болгарском или корейском языке как транслитерированное? Должен ли я иметь дело с тысячами ключевых слов, или у меня проблемы с объединением двух подпрограмм, написанных моими шведскими и египетскими коллегами?
Просто поймите, что ключевые слова программирования написаны на английском языке, так же как музыкальные ключевые слова на итальянском языке.
Это кажется хорошим местом для начала: Языки, не связанные с английским языком.
Там несколько интересных, например Python переведен на китайский язык.
Вы можете использовать препроцессор C/С++ для переопределения всех ключевых слов - и некоторые люди это сделали. Я наткнулся на это, работая тренером/наставником норвежской компании. Некоторая яркая искра реализовала впереди, который перевел все ключевые слова C на норвежский язык и принудительно использовал его. Норвежский персонал, все из которых говорили превосходно по-английски (или я не мог заработать свою кору), все это ненавидели, и он умер смертью.
Я также работал довольно широко в Нидерландах, и большинство программистов, похоже, программируют на английском языке. Единственные люди, с которыми я столкнулся, которые устойчивы к английской гегемонии на языках программирования, (само собой разумеется, говорят по-французски).
Существует одна область, где локализованный язык может быть полезным и полезным, и это DLS (Domain Specific Languages), которые были предназначены для использования не-программистами. Эти языки, безусловно, могут быть локализованы, поскольку бизнес-пользователи из стран, не говорящих по-английски, часто не знают английского языка, а также программистов.
Такие локализованные DSL могут оказаться полезными и для программистов, если они имеют дело с множеством непереводимых терминов. Одна довольно успешная система, с которой я столкнулся, использовалась для расчета заработной платы для персонала израильских военных. Он использовал синтаксис на основе иврита и сотни терминов, которые могут быть правильно выражены на иврите. В этом конкретном случае стандартные логические слова if, then, else и т.д. Были переведены на иврит, а весь редактор кода был справа налево. Таким образом, до сих пор поддерживается очень большая логика бизнеса, и ИМХО справедливо.
Кажется, что это было бы сложно, если бы это не было попыткой сообщества, но для некоторых языков я не понимаю, почему вы не можете сделать существующий язык многоязычным, но создавайте собственные библиотеки, которые локализуют стандартные библиотеки.
Например, в Java вы можете создать
public class HoweverYouSayExampleObjectInYourLanguage extends ExampleObjectName {
}
а затем создайте оберточные функции/методы с именами на вашем целевом языке, но которые в основном вызывают существующие стандартные методы
private void HoweverYouSayExampleMethodInYourLanguage(parameters) {
this.ExampleMethod(parameters);
// Some error handling code
}
Если вы правильно справляетесь с ошибками, трассировка/ошибки стека будут ссылаться на ошибки в стандартных библиотеках, если только это не является ошибкой с реализацией вашей библиотеки локализации - в этом случае это должно быть указано посредством правильной обработки ошибок в самой библиотеке локализации.
Недостатком было бы, как говорили другие люди, обмен исходным кодом. Если бы мы были на одной странице с IDE для данного языка - я не вижу причин, по которым вы не могли бы создать действительно интернационализированную среду IDE, в которой исходный код, который вы видите на экране, не является исходным кодом REAL по сути, но локальный рендеринг реального исходного кода через некоторую форму отображения.
Я собираюсь пойти дальше и сказать, что все, что я только что сказал выше, возможно, в лучшем случае - хорошая идея, потому что имена функций не так важны, как локализованная документация для библиотек и API. то, что в моем опыте сделано ужасно или вообще не для общих языков программирования/контекстов.
Вы можете запрограммировать Perl в латинский.
Не пытайтесь закодировать на естественном языке, что бесполезно. Изучите язык программирования, а не.
Например, слово "switch" ничего не значало для меня на английском языке, но это была инструкция, чтобы выбрать несколько вариантов.
Позже (когда я изучаю английский) я подумал... Эй, это смешно, у английского тоже есть слово "switch", как и C. (doh!)
:)
Независимо от того, насколько хорош или плох ваш английский, вы не можете сказать java
импортировать java.util. * в мой CD-ROM;
Потому что это не допустимый синтаксис.
Как насчет языков типа APL и J? Ключевые слова в APL - это одиночные символы; к сожалению, большинство из них не на вашей клавиатуре, поэтому я пришел и заменил большинство из них ASCII-представлениями (в большинстве случаев состоящими из более чем одного символа).
Сортировано! является двуязычным. Он может понимать как английский, так и немецкий код. Насколько мне известно, Сортировано! это единственный язык программирования, который может это сделать в мире.
Какие-нибудь полезные? Это лучший вопрос.
В значительной степени вы можете программировать в прологе в любом юникоде script (потому что это символический язык). Там (крошечные, weeny) catch-переменные обозначаются начальным капиталом римской буквы во всех компиляторах пролога, с которыми вы, вероятно, столкнетесь, и вам придется переопределить встроенные модули (но пролог делает это относительно легко *).
Я думаю, что пример иллюстрирует то, что я имею в виду лучше всего:
% алгоритм поиска пасхальных дат, данного года (в качестве первого аргумента)
復活節( V1, V2, V3) :-
A 是 (V1 mod 19),
B 是 V1// 100,
C 是 V1 mod 100,
D 是 B // 4,
E 是 B mod 4,
F 是 (B + 8) // 25,
G 是 (B - F + 1) // 3,
H 是 (19*A + B - D - G + 15 )mod 30,
I 是 C // 4,
J 是 C mod 4,
K 是 (32 + 2*E + 2*I - H - J) mod 7 ,
L 是 (A + 11*H + 22*K) // 451,
M 是 (H + K - 7*L + 114) // 31,
N 是 (H + K - 7*L + 114)mod 31,
V2 是 M,
V3 是 N + 1.
/*
Пример теста:
? - 復活節 (2013, V2, V3). V2 = 3, V3 = 31
то есть. Пасха в этом году будет 31 марта
*/
это то, что я использовал, чтобы переопределить сборку в операторе is is (не стреляйте в меня, если она несовершенна):
: -. Соч (500, XFY, 是)
是 (X, Y): -. В (X, Y)