GB inglese o inglese americano?

Question

Se disponi di un'API e sei uno sviluppatore con sede nel Regno Unito e un pubblico altamente internazionale, la tua API dovrebbe essere

setColour()

o

setColor()

(Per prendere una parola come semplice esempio.)

Gli ingegneri con sede nel Regno Unito sono spesso abbastanza difensivi riguardo alle loro ortografie "corrette", ma si potrebbe sostenere che l'ortografia americana è più "standard" nel mercato internazionale.

Immagino che la domanda sia importante? Gli sviluppatori di altre aree locali lottano con l'ortografia di GB o è normalmente evidente cosa significano le cose?

Dovrebbe essere tutto inglese-americano?

Answer 1

Tenderei a usare l'inglese americano perché è diventata la norma in altre API. Parlando come programmatore inglese, non ho alcun problema ad usare " color " ;, ad esempio.

Answer 2

Non sono un madrelingua. Per iscritto, provo sempre a usare en-gb . Tuttavia, nella programmazione uso sempre en-us invece dell'inglese britannico per lo stesso motivo per cui non uso il tedesco o il francese per i miei identificatori.

Answer 3

Dipende da dove vedi la maggior parte dei tuoi clienti. Personalmente preferisco usare l'inglese GB (ad es. Color) nel mio codice privato, ma vado su Color per applicazioni / API / codice pubblicati esternamente!

Answer 4

Generalmente sarei un pignolo per l'ortografia di GB, ma penso che il codice legga molto meglio se è coerente e trovo:

Color lineColor = Color.Red;

apparire molto meglio di:

Color lineColour = Color.Red;

Suppongo che alla fine non abbia davvero importanza.

Answer 5

Anche se di solito sono molto pedante riguardo all'ortografia corretta, come sviluppatore del Regno Unito andrei sempre con l'ortografia americana "color". In tutti i linguaggi di programmazione che ho incontrato, è così, quindi per motivi di coerenza, usare 'color' ha molto senso.

Answer 6

Supponendo che si tratti di un'API Java o C # probabilmente non ha importanza data la pervasività della funzionalità di completamento automatico negli IDE. Se questo è per un linguaggio dinamico o uno in cui gli IDE moderni non sono la norma andrei con l'ortografia americana. Certo che sono americano e quindi ovviamente distorto, ma sembra che la maggior parte del codice che vedo dagli sviluppatori che non sono di madrelingua inglese usano l'ortografia americana per i loro nomi di variabili ecc.

Answer 7

Come programmatore inglese, utilizzo en-US per i miei sviluppatori software. L'inglese americano domina così bene in quasi tutte le altre API che è molto più facile attenersi a un tipo di ortografia e rimuovere l'ambiguità. È una perdita di tempo cercare un metodo solo per scoprire che l'ortografia è disattivata da una lettera a causa delle localizzazioni ortografiche.

Answer 8

Vorrei andare con gli standard attuali e scegliere l'ortografia inglese americano. HTML e CSS sono standard riconosciuti con l'ortografia "color", in secondo luogo, se si lavora con un framework come .NET, è probabile che il colore sia già disponibile in spazi di nomi diversi.

L'imposta mentale sulla necessità di gestire due ortografie ostacolerebbe anziché aiutare gli sviluppatori.

Label myLabel.color = setColour();

Answer 9

Ho problemi con le API che non sono in inglese americano. Solo a causa delle differenze di ortografia. So cosa significano le parole ma la diversa ortografia mi fa inciampare.

La maggior parte delle librerie e dei framework con cui ho familiarità usa l'ortografia americana. Certo, sono americano, quindi ... l'inglese americano è la mia lingua madre.

Answer 10

La maggior parte della documentazione di sviluppo (proprio come MSDN) è in inglese americano.

Quindi potrebbe essere meglio rimanere nel flusso principale e usare l'inglese americano nella tua API se stai prendendo di mira il pubblico internazionale.

Answer 11

Ho ricevuto un altro campione: serializzare e serializzare. :)

Personalmente, non penso che importi molto. Ho lavorato a progetti che utilizzavano paesi di ortografia inglese-britannico e usano l'ortografia inglese. È ancora inglese e non ha molta importanza a causa di Intellisense.

Answer 12

Come canadese, mi imbatto in tutto questo tempo. È molto difficile per me digitare " color " mentre la mia memoria muscolare continua a raggiungere la 'u'.

Tuttavia, tendo ad adottare il linguaggio delle biblioteche. Java ha la classe Color, quindi uso color.

Answer 13

Cerco di trovare parole alternative, se possibile. Lascerò scorrere le dimensioni. Per il colore avrei potuto usare Tonalità, Inchiostro, Primo piano / Sfondo ...

In caso contrario, come inglese, userò en-GB perché mi rimane un po 'di orgoglio nel mio paese e nelle mie origini.

Se dovesse far parte di un progetto più grande, in particolare uno internazionale, manterrei l'intero progetto coerente sopra avendo una piccola parte in una lingua e il resto in un'altra.

Answer 14

Dovrò anche schierarmi con l'inglese americano, semplicemente per mantenere le cose coerenti (come altri hanno già notato qui). Sebbene io sia un madrelingua inglese-americano, ho realizzato progetti software con società di software tedesche e svedesi, e in entrambi i casi la tentazione occasionalmente colpirebbe i miei compagni di squadra nell'usare il testo tedesco o svedese nel codice - di solito per commenti, ma a volte anche per nomi di variabili o metodi. Anche se riesco a parlare quelle lingue, è davvero stonante per gli occhi e rende più difficile portare un nuovo non parlante nel progetto.

La maggior parte delle società di software europee (almeno quelle con cui ho lavorato) si comportano allo stesso modo: il codice rimane in inglese, semplicemente perché ciò rende il codice più adatto alle esigenze internazionali se un altro programmatore dovesse entrare. Tuttavia, la documentazione interna tende generalmente a essere eseguita nella lingua madre.

Detto questo, la distinzione qui riguarda due diversi dialetti dell'inglese, che non è così estremo come vedere due lingue totalmente diverse nello stesso file di codice sorgente. Quindi direi, mantieni l'API in inglese americano, ma i tuoi commenti in inglese GB se ti stanno meglio.

Answer 15

Direi come le altre biblioteche nella tua lingua scelgono e seguono la loro convenzione.

I progettisti del linguaggio di programmazione e le sue API integrate hanno fatto una scelta e se gli utenti sono internazionali o meno sono abituati a vedere l'ortografia coerente con questa scelta. Non stai prendendo di mira oratori di una lingua diversa ma utenti di un linguaggio di programmazione. Le probabilità sono che hanno imparato parecchie parole in lingua straniera dalle API integrate e potrebbero non essere consapevoli che ci sono differenze tra l'inglese americano e l'inglese GB. Non confonderli cambiando i lati dello stagno.

Uso principalmente i linguaggi .NET e .NET Framework utilizza l'ortografia inglese statunitense. Su questa piattaforma, rimarrei con l'inglese americano. Non sono a conoscenza di alcuna lingua standardizzata sull'inglese GB, ma se la tua lo ha fatto, rimani sicuramente coerente con la lingua.

Answer 16

Sono d'accordo con " vai per American " troupe. Io stesso preferisco en-GB quando scrivo e-mail e simili, ma l'inglese americano è praticamente lo standard in tutti i circoli di programmazione.

Answer 17

Anche se l'inglese britannico è ciò che si parla in tutto il mondo - raccomando di usare l'inglese americano che, come altre persone, hanno dominato il mercato.

Answer 18

Sicuramente inglese americano.

Answer 19

Innanzitutto, sono negli Stati Uniti. Nel mio progetto attuale, è sempre " color " tuttavia, la parola per cui non riusciamo a scegliere un'ortografia è "grigia" vs "grigio".

In realtà è diventato abbastanza fastidioso.

Answer 20

Sono una di queste persone che aumenta la frequenza cardiaca e la pressione sanguigna ogni volta che sono costretto a utilizzare l'inglese americano nei file di installazione, ecc. a causa del fatto che il software non offre l'opzione per l'inglese britannico, ma sono solo io :)

La mia opinione personale su questo, tuttavia, sarebbe quella di fornire entrambi gli spelling, dare loro setColor () e setColour (), scrivere il codice in uno di essi e solo far passare il parametro al secondo.

In questo modo rendi felici entrambi i gruppi, a condizione che la tua intellisense diventi un po 'più lunga, ma almeno le persone non possono lamentarsi di te usando il linguaggio "sbagliato".

Answer 21

La selezione della lingua per i nomi degli identificatori non ha nulla a che fare con il pubblico e tutto con la lingua originale in cui è stato sviluppato il framework o l'API.

Non conosco molte lingue ma non riesco a pensare a una sola lingua che usi qualcosa di diverso dall'inglese americano.

I pericoli legati all'introduzione di bug sottili dovuti a ortografia diversa sono IMHO troppo grandi.

Una sostituzione di funzione può facilmente diventare uno pseudo-sovraccarico.

Un file di configurazione potrebbe diventare non valido a causa della differenza di ortografia.

Potrebbe verificarsi una situazione in cui lo stesso oggetto concettuale è stato definito utilizzando più classi, utilizzando sia en-US che en-GB.

Quindi, se un pezzo di codice è puramente per uso interno o anche per uso esterno, gli spelling utilizzati devono sempre corrispondere alla lingua originale della piattaforma / framework / compilatore / API.

Answer 22

Se tutti i tuoi programmatori sono inglesi, usa en-gb. Se il tuo codice verrà visualizzato da programmatori al di fuori della Gran Bretagna, en-us sarebbe una scelta migliore.

Un punto minore, contiamo su un servizio di traduzione per copiare la nostra documentazione in altre lingue. Abbiamo scoperto che otteniamo traduzioni migliori quando utilizziamo en-us come fonte.

Answer 23

Devi considerare il tuo pubblico. Chi utilizzerà il codice e cosa si aspettano di vedere?

Lavoro in una società che ha uffici sia in Canada che in Australia. NOI. Usiamo l'ortografia canadese (molto simile all'inglese britannico) quando produciamo documentazione e codice in Canada e negli Stati Uniti ortografia per ciò che viene utilizzato negli Stati Uniti.

Alcune cose attraversano i confini, ma la differenza nell'ortografia è raramente un problema. Può acutamente generare alcuni dialoghi interessanti quando gli americani non sono a conoscenza di ortografia diversa per Candian e inglese britannico. A volte sono d'accordo con esso, altre volte insistono sul fatto che cambi in "corretto" ortografia. Ciò influisce anche sui formati di data (gg / mm / aaaa in Canada e mm / gg / aaaa negli Stati Uniti)

Quando c'è un vicolo cieco, di solito andiamo con l'ortografia degli Stati Uniti poiché le persone in Canada hanno familiarità con entrambe le varianti.

Answer 24

Il motivo principale che ho sentito per aver scelto l'inglese americano rispetto al Regno Unito è perché il pubblico britannico, quando si confronta con l'ortografia americana, si rende conto che è un'applicazione americana (o presume che sia così), mentre un pubblico americano confrontato con l'ortografia britannica pensa '... ehi, è sbagliato .. non è il colore, non il colore'

Ma come altri hanno già detto, standardizza. Continua e segui.

Answer 25

Mi viene naturale lavorare nell'inglese britannico senza nemmeno pensarci. Tuttavia, se si stanno sviluppando procedure interne, non importa. Se stai creando API che verranno utilizzate pubblicamente e il tuo pubblico è internazionale, perché non implementarle entrambe?

Answer 26

Preferisco l'inglese americano.

Answer 27

Se guardi indietro di qualche centinaio di anni, scoprirai che il cambiamento non ha nulla a che fare con gli Stati Uniti, così come molti lo penserebbero. I cambiamenti derivano da influenze europee, in particolare francesi. Prima di allora, la parola inglese "color" è stato quindi effettivamente scritto "color".

Cercare di standardizzare sarebbe inutile poiché la metà dei bambini cinesi sta imparando l'influenza preeuropea e la comprensione dell'inglese negli Stati Uniti, mentre l'altra metà lo sta riprendendo così com'è oggi, come lingua inglese.

Se pensi che la lingua sia un problema, allora dovresti considerare il Kg di Taiwan che pesa 600g. Devo ancora scoprire come sono riusciti a farlo, ma spero che non vengano mai impiegati come addetti al rifornimento di aeromobili!

Answer 28

Uso sempre en-GB per tutta la mia programmazione. Immagino sia dovuto a una forte influenza dei romanzi britannici.

Tuttavia, potrebbe non essere possibile avere due diversi set di API (uno per en-US, uno per en-GB) che chiamano internamente la stessa funzione? Questo potrebbe gonfiare i file di intestazione, quindi forse a seconda della definizione di un preprocessore, una compilazione condizionale? Se stai usando C ++, potresti fare qualcosa come sotto ...

#ifdef ENGB
     typedef struct Colour
     {
      //blahblahblah
     };
     void SetColour(Colour c);
#else
    typedef struct Color
    {
      //blahblahblah
    };
    void SetColor(Color c);
#endif

A seconda che il programmatore client definisca ENGB o meno come di seguito

#define ENGB

potrebbe usare le API nella cultura che preferisce. Forse eccessivo per uno scopo così banale, ma hey, se sembra importante, perché no! :)