Scegliere tra parole con diverse grafie per i nomi di funzioni

Scegli ciò che ha senso per la tua organizzazione / progetto, documenta la tua scelta e usala in modo coerente. Non c'è davvero alcuna linea guida universale per questo.

Se la maggior parte dei tuoi sviluppatori lo scrive "al centro", allora potrebbe essere sensato standardizzare l'ortografia "Inglese britannico" rispetto all'ortografia "Inglese americano" del "centro", poiché questo è ciò che più le persone saranno abituate.

OTOH, se stai lavorando con una o più API / framework / toolset che usano l'ortografia "American English", potresti star meglio attenendoti per coerenza con quelli.

Ma ancora una volta, documenta la tua decisione - non solo ciò che decidi, ma perché e assicurati che tutti abbiano letto, compreso e compreso; accettato di seguirlo.

when developing international projects, it is common sense to use English as the reference language since it is the language that the most people understand

Per lo stesso motivo, è di buon senso usare l'inglese americano (en-US), non altri accenti regionali o dialetti :

• it-US è utilizzato in tutti i progetti internazionali che ho visto. Passare da en-US a, ad esempio en-NZ (Nuova Zelanda) sarebbe doloroso e creare incoerenze tra la base di codice che scrivi e le API che usi.

• Le varianti diverse da en-US sono meno note rispetto a en-US. Ecco perché sono completamente in disaccordo sia con il commento di Joel Brown che con la risposta di alroc: se segui la loro logica, ti ritroverai a usare il tedesco se sei in Germania o lo spagnolo se sei in Spagna.

  1. O stai scrivendo un progetto locale e sei completamente sicuro che non verrà mai utilizzato da uno sviluppatore straniero. In questo caso, in primo luogo, non sei obbligato ad attenersi all'inglese e molti sviluppatori useranno la loro lingua.

  2. O il tuo intento è sviluppare un progetto internazionale, che significa usare l'inglese americano, non l'inglese usato in Australia o in Irlanda.

• Se stai utilizzando una lingua diversa dall'inglese americano, sarebbe coerente utilizzare anche la localizzazione non americana (non a livello di interfaccia utente, ma in codice e documentazione). Questo crea ulteriore complessità non necessaria.

• Immagino che per le persone che hanno l'inglese come lingua madre, è piuttosto semplice capire qualsiasi dialetto inglese o accento regionale. Questo non è il caso per gli stranieri. Gli sviluppatori che lavorano in India, Cina, Russia sono abituati all'inglese americano e per loro (per noi), l'uso di altre varianti è doloroso.

  Nota: questa è ancora solo la mia esperienza di sviluppatore francese e ciò che alcuni di indiani e russi mi hanno detto. Dai commenti emerge che alcuni altri stranieri sono più abituati a en-UK.

  Ad esempio, non ho problemi a guardare un film in inglese americano, ma difficilmente riesco a capire alcuni film girati in Scozia o nel Galles. L'inglese scritto è più uniforme, ma è ancora leggermente più difficile da leggere e in particolare scrive per gli sviluppatori stranieri.

  Usare l'inglese solo in un contesto professionale peggiora le cose. Quando l'unico uso dell'inglese per uno sviluppatore russo è il suo lavoro, la persona sarà abituata a scrivere colore o centro e colore o < em> center sarà percepito come un errore ortografico; pochi secondi dopo, la persona capirà che si tratta di una corretta ortografia di una parola in un altro accento regionale.

• I correttori ortografici, i browser e altri strumenti sono generalmente configurati per essere utilizzati nell'inglese americano. Lavorare su un progetto che utilizza altre impostazioni locali richiederà un ambiente di sviluppo dedicato o una riconfigurazione costante degli strumenti se lo sviluppatore deve mantenere più progetti contemporaneamente.