Inglese GB o inglese americano?

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

setColour()

o

setColor()

(Per prendere una parola come un semplice esempio.)

Gli ingegneri con sede nel Regno Unito sono spesso piuttosto difensivi riguardo alla loro ortografia "corretta", ma si potrebbe sostenere che l'ortografia statunitense è più "standard" nel mercato internazionale.

Immagino che la domanda sia: importa? Gli sviluppatori in altre località hanno problemi con l'ortografia GB o è normalmente abbastanza evidente cosa significano le cose?

Dovrebbe essere tutto inglese americano?

Tenderei a usare l'inglese americano poiché è diventato la norma in altre API. Parlando come programmatore inglese, non ho alcun problema ad usare "colore", per esempio.

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

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

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

Color lineColor = Color.Red;

per avere un aspetto molto migliore di:

Color lineColour = Color.Red;

Immagino che alla fine non abbia davvero importanza.

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

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. Ovviamente sono americano e quindi sono ovviamente di parte, ma sembra che la maggior parte del codice che vedo da sviluppatori che non sono madrelingua inglesi usino l'ortografia degli Stati Uniti per i loro nomi di variabili, ecc.

Come programmatore inglese, utilizzo en-US per il mio sviluppatore di 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 è errata di una lettera a causa delle localizzazioni ortografiche.

Vorrei seguire gli standard attuali e scegliere l'ortografia inglese americano. HTML e CSS sono standard riconosciuti con l'ortografia "colore", in secondo luogo, se stai lavorando con un framework come .NET, è probabile che tu abbia già il colore disponibile in diversi spazi dei nomi.

La tassa mentale per avere a che fare con due ortografie ostacolerebbe piuttosto che aiutare gli sviluppatori.

Label myLabel.color = setColour();

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 che conosco utilizzano l'ortografia degli Stati Uniti. Ovviamente sono americano quindi ... l'inglese americano è la mia lingua madre.

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

Quindi potrebbe essere meglio rimanere con il flusso principale e utilizzare l'inglese americano nella tua API se ti rivolgi a un pubblico internazionale.

Ho un altro campione: Serializza e Serializza. :)

Personalmente, non credo che importi molto. Ho lavorato a progetti che utilizzavano paesi di ortografia inglese-britannica e utilizzano l'ortografia britannica. È ancora inglese e non ha molta importanza grazie a Intellisense.

Come canadese, mi imbatto in questo tutto il tempo. È molto difficile per me digitare "colore" poiché la mia memoria muscolare continua a raggiungere la "u".

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

Se possibile, cerco di trovare parole alternative. Lascerò scorrere. Per il colore potrei eventualmente usare Tonalità, Inchiostro, Primo piano / Sfondo ...

Altrimenti, come inglese, userò en-GB perché ho ancora un po 'di orgoglio nel mio paese e nelle mie origini.

Tuttavia, se dovesse far parte di un progetto più grande, soprattutto internazionale, manterrei l'intero progetto coerente al di sopra di avere una piccola parte in una variazione linguistica e il resto in un'altra.

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 sia tedesche che svedesi, e in entrambi i casi la tentazione di tanto in tanto colpiva i miei compagni di squadra di usare testo tedesco o svedese nel codice - di solito per i commenti, ma a volte anche per nomi di variabili o metodi. Anche se posso parlare quelle lingue, è davvero fastidioso 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ù amichevole internazionale se un altro programmatore dovesse partecipare. Tuttavia, la documentazione interna di solito tende a essere eseguita nella lingua madre.

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

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

I progettisti del linguaggio di programmazione e delle sue API incorporate hanno fatto una scelta e, indipendentemente dal fatto che gli utenti siano internazionali o meno, sono abituati a vedere l'ortografia coerente con questa scelta. Non stai prendendo di mira altoparlanti di una lingua diversa ma utenti di un linguaggio di programmazione. È probabile che abbiano imparato alcune parole nella lingua straniera dalle API integrate e potrebbero non essere consapevoli delle differenze tra l'inglese americano e l'inglese GB. Non confonderli cambiando lato dello stagno.

Uso principalmente i linguaggi .NET e .NET Framework utilizza l'ortografia dell'inglese americano. Su questa piattaforma, preferirei l'inglese americano. Non sono a conoscenza di alcuna lingua standardizzata sull'inglese GB, ma se il tuo lo ha fatto, resta assolutamente coerente con la lingua.

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

Anche se l'inglese britannico è quello che si parla in tutto il mondo, consiglio di usare l'inglese americano che, come altre persone hanno detto, domina il mercato.

Sicuramente inglese americano.

Primo, sono negli Stati Uniti. Nel mio progetto attuale, è sempre "colore", tuttavia, la parola per la quale non riusciamo a scegliere un'ortografia è "grigio" rispetto a "grigio".

In realtà è diventato piuttosto fastidioso.

La selezione della lingua per i nomi degli identificatori non ha nulla a che fare con il pubblico e ha tutto a che fare 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 che utilizzi qualcosa di diverso dall'inglese americano.

I pericoli di introdurre bug sottili a causa di ortografie diverse sono troppo grandi IMHO.

Un override 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, quindi, sia che un pezzo di codice sia puramente per uso interno o anche inteso per uso esterno, l'ortografia utilizzata deve sempre corrispondere alla lingua originale della piattaforma / framework / compilatore / API.

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

Un punto minore, ci affidiamo a un servizio di traduzione per copiare la nostra documentazione in altre lingue. Abbiamo riscontrato di ottenere traduzioni migliori quando si utilizza en-us come fonte.

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

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

Alcune cose attraversano i confini, ma la differenza nell'ortografia è raramente un problema. Acutally può generare alcuni dialoghi interessanti quando gli americani non sono a conoscenza di ortografie diverse per il candiano e l'inglese britannico. A volte sono d'accordo, altre volte insistono affinché cambi l'ortografia "corretta". Ciò influisce anche sui formati della data (gg / mm / aaaa in Canada e mm / gg / aaaa negli Stati Uniti)

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

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

Ma come altri hanno detto, standardizzare. Scegli e resta fedele.

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

Preferisco l'inglese americano.

Sono una di queste persone la cui frequenza cardiaca e pressione sanguigna aumentano 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 è solo me :)

La mia opinione personale su questo, tuttavia, sarebbe di fornire entrambe le ortografie, dare loro setColor () e setColour (), scrivere il codice in uno di essi e fare in modo che il secondo passi i parametri.

In questo modo mantieni felici entrambi i gruppi, ammesso che il tuo intellisenso si allunghi un po ', ma almeno le persone non possono lamentarsi che usi il linguaggio "sbagliato".

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

Tentare di standardizzare sarebbe inutile poiché la metà dei bambini cinesi sta imparando l'influenza pre-europea e la comprensione dell'inglese negli Stati Uniti, mentre l'altra metà la sta adottando per come è oggi, come lingua inglese.

Se pensi che la lingua sia un problema, dovresti considerare il Taiwan Kg che pesa 600 g. Devo ancora scoprire come ci sono riusciti, ma spero che non vengano mai impiegati come personale addetto al rifornimento di aerei!

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 però gonfiare i file di intestazione, quindi forse dipende da una definizione del preprocessore, una compilazione condizionale? Se stai usando C ++, potresti fare qualcosa come di seguito ...

#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! :)