Qual è l'estensione dei dialetti di localizzazione del linguaggio di programmazione?

My question is: what other languages, if any, implement a similar paradigm for programming language internationalization?

Fortunatamente, per quanto ne so, non ce ne sono. Spero ardentemente che rimanga così.

La localizzazione di qualsiasi cosa importante in una lingua o in una API o in uno qualsiasi dei vari simboli e stringhe definiti da cui dipendono i programmi, ogni volta che li ho attraversati, è un disastro assoluto. Di recente abbiamo riscontrato la situazione in cui il software non può essere installato su una versione spagnola di Windows perché il gruppo definito dal sistema solitamente chiamato "Tutti" è chiamato "Todos" in spagnolo. Abbiamo sistematicamente problemi con cose semplici come i formati di data negli Stati Uniti e il separatore decimale in Germania. Questi sono problemi che nessuno deve aver incorporato nel loro codice sorgente.

Per non dire che sto cercando vantaggi sleali per l'inglese, in pratica penso che sia vero il contrario. Gli sviluppatori in lingue diverse dall'inglese possono tipicamente utilizzare una vasta gamma di nomi definiti tratte dalla propria lingua senza timore di confusione con le parole riservate e i simboli API forniti dall'ambiente di sistema. Vedo questo come un vantaggio.

Esistono strutture di localizzazione e internazionalizzazione per le applicazioni, spesso come funzioni di libreria (ad esempio Posix gettext ).

^{Negli anni '60 e '70 in Francia sono comparsi diversi linguaggi di programmazione con parole chiave francesi, ad es. PAF e LSE .}

Tuttavia, ha molto meno senso localizzare il codice sorgente di programmi e script (ad esempio cambiando le parole chiave dei linguaggi di programmazione come if a si in francese ....) perché anche il significato di un programma è trasmesso dai nomi degli identificatori e dai commenti.

Le traduzioni automatiche e affidabili (e fedeli) di tali nomi e commenti sono IMHO oltre lo stato dell'arte.

^{E credo che sarebbe più semplice avere il programma della macchina stesso, cioè sintetizzare il proprio codice, invece di tradurre programmi per essere umanamente comprensibili da altre culture. Guarda Intelligenza generale artificiale e ad es. blog di J.Pitrat .}

In pratica, gli sviluppatori di software su cui lavorare alcuni team internazionali (ad esempio progetti di software libero) dovrebbero concordare su un linguaggio umano (spesso una qualche forma di inglese) e su alcune convenzioni di codifica o stili di codifica.

Alcune lingue non hanno parole chiave (es. APL o anche PL/1 dove lo stesso nome IF può avere sia un ruolo di parola chiave sia un ruolo di identificatore, in modo che IF IF=THEN THEN; sia un valido ma un'affermazione PL / 1 criptica), ma hanno identificatori e sviluppatori che danno nomi significativi agli identificatori della propria cultura. La traduzione automatica di questi non è realistica.

Alcune pochissime pubblicazioni menzionano l'utilizzo di tecniche di elaborazione della lingua naturale su commenti ed identificatori in analisi del programma statistico del codice sorgente. (Sono interessato a riferimenti aggiuntivi)

A proposito, guarda COBOL ; Credo che sia stato progettato con l'ingenua affermazione che il codice sorgente sarebbe diventato leggibile dai non programmatori.

Alcuni insegnanti francesi hanno insegnato a programmare in C definendo macro come

// French equivalent of some C keywords
#define si if
#define sinon else
#define faire do
#define tantque while
#define pour for

ma questo è diventato fuori moda. Ora la maggior parte degli insegnanti in Francia sulla programmazione richiede una certa padronanza della lingua inglese.

^{(Mi interessa se oggi, nelle università cinesi o arabe, viene fatto un equivalente)}