Problemi di denominazione del dominio non inglese nella programmazione

Question

La maggior parte del codice di programmazione, immagino sia scritta in inglese. Ma sono curioso di sapere come le persone gestiscono il problema della denominazione in questo documento. Gran parte della programmazione viene eseguita all'interno di un dominio aziendale, di solito con termini ben definiti per determinate procedure, articoli.

Io vengo dalla Danimarca, per esempio, e qualcosa con cui lavoro molto ha un termine chiamato "indblikskode", che si traduce in "codice dell'insight". Quindi, devo usare la riga "string indblikskode = ..." nel codice C# per qualche servizio web relativo a questo? O cerco di utilizzare una traduzione, come "insightcode"? La bussiness in cui mi trovo non è nemmeno coerente nella sua lingua, ad esempio usando il termine "organisatorisk enhed" (unità organizzativa), ma altrettanto spesso usando l'abbreviazione "OU", che è ovviamente abbreviata dall'inglese.

In che modo altre persone gestiscono questo problema di denominazione, pur mantenendo coerenti e sensati (in tutto, dai nomi di variabili semplici nel codice, alle tabelle del database, ai nomi dei server)?

Duplicati:

• Should identifiers and comments be always in English or in the native language of the application and developers?
• Do you use another language instead of English?

Answer 1

Vedere le mie domande e risposte here.

Fondamentalmente dipende dalla vostra organizzazione e dall'applicazione. Se la vostra azienda, gli sviluppatori e i clienti parlano tutti la stessa lingua madre e vi aspettate che rimanga tale, sarebbe estremamente controproducente far sì che tutti diventino anche loro un traduttore part-time. Notevole perdita di produttività per un vantaggio futuro puramente ipotetico. YAGNI.

Se si tratta di una grande azienda internazionale, o se ci sono piani concreti per espandersi a livello internazionale o avere un lavoro svolto in mare aperto, è una questione diversa, ovviamente.

Answer 2

posso parlare solo per me, ma ho sempre tradurre termini in inglese per la denominazione classi e variabili, ed è uno dei nostri non scritta meglio pratiche di codifica per fare altrettanto. Non si sa mai quando si potrebbe aver bisogno di passare dallo sviluppo alla manodopera più economica all'estero o al consulente esperto di expat in città.

Answer 3

Avendo lavorato in Svizzera (lato tedesco cioè Zurigo) e vissuto in Germania per un periodo di tempo, posso dirti che devo ancora vedere un ambiente in cui il codice non è in inglese. Certo, l'applicazione potrebbe essere in tedesco (ma molti ambienti professionali sono comunque di lingua inglese) ma il codice (che ho visto) è praticamente tutto inglese.

È difficile scrivere codice in altre lingue. Per prima cosa, le API sono (quasi) tutte in inglese. Java usa la denominazione JavaBeans ad esempio, quindi è necessario utilizzare set e ottenere comunque e "getGeburtstag" non ha proprio lo stesso ring di "getDateOfBirth".

Altri paesi possono variare per questa è stata la mia esperienza dai paesi germanici.

Answer 4

Utilizziamo solitamente termini inglesi stabiliti (il nostro dominio aziendale di solito ha termini in inglese), ma se non riesco a trovare un termine adatto, potrei usare anche il finlandese. Diamine, anche i nostri commenti nel codice sono in lingue miste ...

Ovviamente l'approccio ragionevole dipende in gran parte dal fatto che il codice sorgente verrà mai utilizzato all'esterno dell'edificio. In un piccolo negozio non è un grosso problema.

Answer 5

Sto lavorando in una società in Austria (quindi parliamo tedesco) e stiamo programmando in inglese (nomi di variabili, oggetti dominio, GUI). Lo rende un po 'più ingombrante, perché devi trovare le traduzioni in inglese e devi tradurre la GUI prima di rilasciare il programma. Non sono sicuro che tutti i nomi siano veramente corretti.

Al contrario nella ex azienda stavo lavorando per programmato rigorosamente in tedesco. Questo è stato abbastanza bello (anche se le parole tedesche tendono ad essere più lunghe delle parole inglesi). Dopo alcuni anni l'azienda voleva utilizzare lo stesso programma negli Stati Uniti, quindi i programmatori che parlavano inglese dovevano usare lo stesso codice base. dopo questo tutto è diventato abbastanza incoerente - variabili, campi del database ..in entrambe le lingue (i membri del team di lingua inglese non parlavano tedesco).

La mia esperienza è che è più facile gestire l'internazionalizzazione all'inizio (si è obbligati a farlo quando si scrive il programma in inglese) di un'applicazione, perché non è molto divertente localizzare un'applicazione da 10000 LOC. Il vantaggio di scrivere in un'altra lingua è che vedi immediatamente ciò che è localizzato e ciò che non lo è, anche se è il lavoro che devi prendere in considerazione per questo.

Per le parole intraducibili: non l'avevamo ancora annunciato - nonostante fosse un lavoro trovare la frase inglese per "consegne intracomunitarie" (che è una cosa dell'UE). Ma se ciò accadesse, sono abbastanza sicuro che useremmo la parola tedesca.

Answer 6

Vivo e lavoro in Germania, ma solo codice inglese. Rende le cose più facili. Puoi pubblicare il tuo codice in rete se vuoi porre domande o vuoi pubblicare tutorial sul tuo lavoro.

Anche il codice sembra più "professionale" per me.

Answer 7

Il problema con la denominazione non inglese di classi e funzioni è che si finisce invariabilmente con pidgin macaronico. Le parole chiave sono in inglese, le convenzioni di denominazione (come ad esempio i getter/setter) sono anche in inglese, lo stesso per i nomi standard per i modelli di progettazione.

si sta andando a finire con roba come:

OrganisatoriskEnhedFactory::getInstance()->getIndblikskode(); 

Answer 8

Ho anche vivere e lavorare in Germania per ora e noi per lo più utilizzare l'inglese ad eccezione di alcuni vecchi commenti in tedesco. Penso che i commenti non inglesi siano generalmente una pessima idea dato che dovrai dedicare del tempo a cercare di capirlo (e capire correttamente). Sebbene sia il tedesco che l'inglese non siano le mie lingue native, il codice scritto in qualcosa di diverso dall'inglese sembra essere bizzarro.

Non saprai mai chi lavorerà al tuo codice il giorno successivo. Quindi dovresti usare il linguaggio IT universale.

P.S. Dal momento che non mi piacciono le lingue non inglesi nel mio ambiente di sviluppo, ho fatto arrabbiare un amministratore locale quando ho rifiutato di installare il mio PC con Windows tedesco, Office tedesco e Visual Studio tedesco. Ci sono volute molte ore per scaricare le versioni inglesi solo per me.

Anche se penso che sia un giorno utile installare un language pack o solo una copia diversa dello stesso software solo per imparare la terminologia. SQL Management Studio in francese mi rende davvero entusiasta, proprio come quando ho provato a passare da Skype allo spagnolo.