Come nominare parti del tuo programma come madrelingua inglese non madrelingua [duplicato]

Parlando di un buon decennio di programmazione ...

Io codifico sempre in inglese, perché questo è per me il linguaggio del codice nativo. È così in ogni serio testo di programmazione, e anche tutta la letteratura scientifica e non scientifica è in inglese.

Tutto ciò che è codice, dati, qualunque sia l'inglese.

Le stringhe e il testo visualizzato ecc. sono localizzati (con segnaposto anche in inglese). Il primo prodotto finale è sempre inglese. Seguono le localizzazioni (che di solito sono solo file di stringa aggiunti).

Ho visto del codice (OCE, Salome) che è stato scritto da persone che stavano pensando in una lingua straniera. Non mischiavano molto i linguaggi, ma quando lo facevano rendeva molto difficile pubblicare i commenti attraverso il software di traduzione!

Bottom line - stick with one language. Nessuna abbreviazione, nessun gergo e usa parole comuni e una grammatica corretta. Fallo e potrei ottenere l'essenza dei tuoi commenti e nomi di variabili con un traduttore e / o con un'ipotesi plausibile.

La strategia che ho trovato migliore è quella di avere il vocabolario spesificativo del dominio nella lingua nativa, nel mio caso norvegese, e tutto il resto, compresi i commenti al codice, le tabelle db, i nomi dei file, ecc. in inglese. Se una tabella o un file di database ha, come parte del suo nome, una parola spesifica di dominio, quella parola non è ancora tradotta. Ciò significa che si possono incontrare nomi come barnepensjonMainTable (Barnepensjon è una pensione extra che si ottiene se si è pensionati in Norvegia e ha un bambino di età inferiore ai 18 anni se ricordo bene), che in superficie sembra sciocco, ma è facile da capire per un madrelingua e usa il vocabolario spesifico del dominio nativo. Ciò significa che, in base a nomi di variabili, nomi di file o altre informazioni, è possibile chiedere agli esperti di dominio il termine senza traduzione (possibilmente con perdite).

La chiave principale qui è la coerenza. Solo tutte le parole spesifiche non di dominio non dovrebbero MAI essere nella lingua nativa, le parole spesifiche del dominio non dovrebbero MAI essere tradotte. Su progetti di grandi dimensioni questo è particolarmente vero poiché diversi programmatori (ben intenzionati) possono tradurre parole spesifiche di dominio in una sconcertante serie di parole simili. Questo rompe qualsiasi "ricerca in tutti i file" e aggiunge confusione.

Per i progetti più piccoli uso tutto l'inglese.

Per i progetti in lingue miste che rompono i principi di cui sopra, cerco semplicemente di estendere i principi che il progetto utilizza, poiché la coerenza è più importante dei principi di cui sopra.

Ho esperienza di questo essere il madrelingua inglese che riceve codice scritto da programmatori di altri paesi.

Penso che sia semplicemente una buona pratica scrivere i nomi delle variabili / nomi delle tabelle ecc in inglese per alcuni motivi. Non sai mai cosa succederà in futuro, il codice su cui stai lavorando ora potrebbe essere solo per un progetto interno, ma potrebbe anche essere trasferito in un altro ufficio in futuro o potrebbe essere qualcosa che tu o la tua azienda decidere di vendere come il prodotto cresce.

Avere i tuoi nomi in inglese significa che puoi trasmettere il tuo codice non solo agli sviluppatori di lingua inglese nativa, ma agli sviluppatori che potresti incontrare, l'inglese potrebbe non essere la loro lingua madre, ma capiranno abbastanza in generale per avere l'idea di quali sono i tuoi nomi significare.

Mentre i programmatori possono avere difficoltà con alcuni nomi in inglese, GoogleTranslate e / o un dizionario è in genere abbastanza per tradurre in modo univoco parole singole. Dal momento che l'inglese non ha parole maschili / femminili non è troppo difficile per ottenere i nomi corretti o abbastanza vicino.

Avere i nomi inglesi rende anche più facile esternalizzare il lavoro e / o ottenere supporto da parti esterne. Immagina di dover integrare qualcosa nel tuo codice di cui non hai esperienza e decidere di esternalizzarlo a un altro programmatore. Se i tuoi nomi non sono in inglese, questo programmatore o ti deve infastidire per scoprire cosa significhi o tradurlo da solo, entrambe queste opzioni perdono tempo.

Dalla mia storia ho lavorato di recente su un codice che è stato scritto da una società francese, tutte le tabelle / colonne del database / nomi dei report (e testo) ecc. erano in francese, dato che io e il collega con cui lavoravo avevamo Pochissima conoscenza del linguaggio che abbiamo dovuto usare costantemente GoogleTranslate, questo ha rallentato l'intero compito, alla fine abbiamo imparato alcune delle parole, ma ha reso il compito molto più noioso e prolisso di quanto avrebbe dovuto essere. Se lo sviluppatore iniziale lo avesse considerato durante lo sviluppo di questo database, il nostro compito avrebbe richiesto metà del tempo.

La GUI è meglio scrivere usando i file di risorse per contenere il testo, in questo modo puoi facilmente avere il tuo software in grado di supportare più lingue. Anche se questo può sembrare eccessivo per alcuni progetti, è bello essere a prova di futuro e per il piccolo sforzo in più puoi rendere il tuo lavoro a prova di futuro in un modo.

L'unico posto in cui direi che sarebbe accettabile usare nomi non inglesi è forse nella progettazione di siti web in cui l'utente vedrà l'URL completo con cartelle, ad esempio www.yourURL.com/subfolder/filename.htm in questa situazione se il tuo il sito Web non è per un pubblico internazionale, è opportuno utilizzare nomi di file / cartelle non inglesi.

Tutto quanto sopra dovrebbe idealmente essere parte di un documento standard di programmazione ben pianificato che non solo include la lingua per nominare le cose, ma anche il caso da usare e lo stile grammaticale.

Seguendo la mia esperienza personale con questo:

Ho visto un bottino di progetti che sono esattamente programmati come hai detto; due lingue, slang e scorciatoie personalizzate e tutto ciò che è stato mescolato dal livello persistente al livello di presentazione.

All'epoca in cui ho iniziato a lavorare in azienda, ho continuato a lavorare dichiarando l'inglese come linguaggio di programmazione per tutti i nuovi progetti. È stato difficile al primo tentativo e molto codice deve essere rivisto, ma ha funzionato almeno dopo 3 mesi. Ora tutti i progetti sono scritti in inglese dalle tabelle del database rispetto alla gestione delle eccezioni in Fronted (alcuni progetti richiedono ancora una sola lingua in modo che qui l'inglese venga ancora saltato in alcuni progetti).

Devo menzionare che stiamo sviluppando con .NET ei file di risorse sono un pilastro importante per questa configurazione. Quasi sei mesi dopo che ho iniziato questo, tutti i programmatori hanno concordato che ora il codice è meglio da leggere e il processo di sviluppo è veloce come prima. Sicuramente stai pensando nella tua lingua madre, ma ha bisogno solo di un po 'di allenamento per scrivere tutto in inglese. La documentazione del progetto al di fuori del codice del programma viene ovviamente ancora scritta nella nostra lingua nativa.

Con l'uso dei file di risorse è facile tradurre i nostri progetti mentre tutte le altre parti non hanno bisogno di modifiche perché abbiamo dichiarato la lingua di programmazione in inglese, quindi nessuna tabella o variabile del database avrà bisogno di una traduzione. Per non parlare del fatto che ogni programmatore dovrebbe seguire le regole di base per nominare breve e diretto.

La mia esperienza qui in Brasile è che molte persone con cui ho lavorato tendono a mescolare molto il portoghese e l'inglese, che si tratti di variabili, classi, colonne di database, nomi di funzioni, ecc.

Anche se, per essere onesti, il portoghese è facile da usare nel linguaggio di programmazione, poiché possiamo facilmente leggere i segni di accentuazione mancanti come ~ o a ç. Ad esempio, "promoção" risulterebbe come "promocao" per scopi di codifica, e ogni programmatore potrebbe guardarlo e indovinare "in realtà è promoção".

Personalmente, direi che, a meno che la tua lingua nativa usi molti caratteri speciali, e la loro presenza o ausence faccia la differenza, usala principalmente, attenendoti all'inglese solo per le convenzioni come "get" e "set" "per Java. A meno che tu non stia sviluppando per clienti stranieri. In tal caso, l'inglese completo è la scelta migliore.

Da quello che ho letto, i nativi non inglesi tendono ad essere d'accordo sul fatto che la migliore pratica è quella di scrivere tutto il codice in inglese (la GUI può rimanere la stessa). Questo non è solo perché la maggior parte dei linguaggi di programmazione sono in inglese, ma perché l'inglese è un linguaggio altamente tecnico, quindi puoi essere molto preciso e non ambiguo nelle convenzioni di denominazione, nei commenti, ecc.

Io nomino sempre tutti gli identificatori nel programma in inglese. Sono un madrelingua inglese non nativo. Se non conosco la parola giusta per una variabile specifica, utilizzo solo il dizionario online per trovare quello giusto.

La GUI è una lingua singola (se non è pensata per essere utilizzata a livello internazionale) o multi-lingua (con file di testo locali o qualcosa del genere, a seconda della piattaforma).

Non confondere programmazione e GUI / altre interazioni con l'utente. Per un linguaggio di programmazione, devi usare il linguaggio più semplice e semplice senza accenti o altre cose del genere. Ad esempio, non è possibile programmare in giapponese con la scrittura in romanji poiché si avrebbero seri problemi con gli accenti che influenzano la pronuncia.

Il migliore per ora è ancora l'inglese (non ho familiarità con altre lingue), lavoro in un team di programmazione francese e ogni volta che qualcuno usa un nome francese per un nome di metodo è un casino perché gli accenti sono davvero importanti in francese. Ecco perché usiamo l'inglese. La linea di fondo è che puoi usare qualsiasi lingua purché tu possa scriverla in puro alfanumerico (a-z0-9). O potresti usare un linguaggio di programmazione / compilatore che accetta tutti i caratteri in sintassi ma non ne conosco.

Vengo da Israele, la mia lingua madre è l'ebraico e programma sempre in inglese.

È molto più comodo (anche se l'ebraico è rtl mentre le lingue inglesi e latine sono ltr, quindi è doloroso leggere se è in ebraico, non so come sia nelle lingue di ltr come l'olandese) .

Lo trovo molto più efficiente.

Quando ho iniziato a programmare preferivo il ceco (la mia lingua madre). Era più ovvio quale sia la funzione di una lingua o la funzione di libreria e quale sia puramente la mia scelta di nome. Mi è piaciuto particolarmente per gli esempi che ho adottato: era chiaro cosa deve rimanere e cosa può essere scagliato.

Ora preferisco l'inglese anche se è solo un mio progetto personale. Sembra più fluente con le parole chiave della lingua e le funzioni della libreria. Se non mi aspetto una futura necessità di localizzazione scrivo le stringhe direttamente nella lingua della GUI. A volte uso un linguaggio incoerente per i commenti: inglese per documentazione e ceco per osservazioni e todo: note. Uso specifici caratteri cechi come ěščřž (nome valido in C #) per variabili di debug unidirezionali - li rende più facili da trovare in seguito poiché non li uso da nessun'altra parte nel codice.

Questa è la regola che uso:

1- I termini specifici del dominio sono sempre nella lingua del cliente / cliente.

2- I termini del computer sono sempre in inglese.

Il mio abile linguaggio è francese. I miei clienti scrivono le loro richieste in francese, parlano in francese, la gui è in francese, ecc.

Se metti tutto in inglese, hai qualche mappatura mentale in cui l'applicazione visualizza la parola francese "Avis Juridique", ad esempio, ma questi sono memorizzati in una tabella di database il cui nome è in inglese, ad esempio "Consulenza legale" (google's propria traduzione).

Ciò che può accadere allora è che gli sviluppatori parlano agli utenti con i termini inglesi, e i clienti non hanno idea di cosa stia parlando lo sviluppatore.

La peggiore traduzione può essere fuorviante. Per esempio nella transalazione che ho menzionato prima mentre Avis può significare Advice, questo potrebbe non essere necessariamente l'uso corretto che sto cercando.

Se ho una fabbrica di "Avis Juridique", la chiamerò AvisJuridiqueFactory.

Ho iniziato con una base di codice tedesca, ma quando la mia azienda diventa più internazionale, gli sviluppatori dovrebbero documentare tutto in inglese. Alcuni lo fanno, altri no. Coloro che hanno lavorato in team internazionali passano all'inglese.

Scrivo tutti i miei programmi in inglese, anche i programmi solo per uso tedesco (spesso iniziano solo in tedesco, poi sono necessari in altri paesi).

Quando ho un codice complesso, passo al tedesco. Se ho problemi a spiegare qualcosa nella mia lingua madre, non cerco di spiegarlo in una lingua straniera. Aggiungo una breve (o lunga) spiegazione inglese e aggiungo la documentazione tedesca, nel caso non comprenda il mio inglese.