Sono un membro di un piccolo nuovo team e con una delle nostre ultime build ho notato che i file di codice VS2010 non contengono la formattazione della lingua.
Quindi ad esempio quando scrivo un simbolo dell'euro nel mio codice o uso un "." o "," in numeri o utilizzare simboli Pounds, Euro o Dollar, quelli sembrano ok nel mio codice, ma per un programmatore in Russia non lo fanno. Mi chiedo in che modo le altre persone affrontano questo tipo di problemi?
I caratteri non-ascii sono dolorosi in Visual Studio. Sebbene il nostro team non sia composto da persone che utilizzano impostazioni locali diverse, abbiamo occasionalmente bisogno di caratteri provenienti da diverse località e utilizziamo diversi altri compilatori che si comportano diversamente. Quindi ecco cosa abbiamo trovato funziona:
Quindi usa UTF-8 per far sì che i file vengano visualizzati correttamente per tutti, ma in stringhe strette devi sempre usare gli escape comunque. Puoi usare i caratteri direttamente in letterali di grandi dimensioni, ma se hai mai bisogno di eseguire il porting del codice, usando le sequenze di escape preferirai comunque. Non è leggibile, sì. Puoi avere il testo attuale nel commento, verrà visualizzato correttamente se è UTF-8.
Hm, che era in particolare per la codifica , che so è possibile di worm in Visual Studio. Per le altre cose, nei commenti si usa solo una lingua comune, di solito l'inglese. E nell'output utente devi usare std::locale .
Per quanto riguarda la localizzazione effettiva, il sistema risorse per impostazione predefinita fornito da Microsoft toolchain è notoriamente difficile da mantenere . Raccomando vivamente di utilizzare il sistema, che contiene inglese letterali direttamente nel codice e cataloghi di traduzione dall'inglese all'altra lingua. Ciò garantisce che non ti dimentichi di aggiornare le traduzioni quando cambia la fonte.
Utilizza Gettext , che ora può essere letto da Boost.Locale o framework simile (ad es. Qt ha un sistema simile integrato (e KDE lo sostituisce comunque con Gettext)).
Boost.Locale fornisce anche alcune funzioni che utilizzano std::locale più conveniente. Ampliata la funzione tipicamente estesa di printf-like estesa a supportare internamente i formati std::locale number / currency / date ...
Una soluzione è avere un documento che delinea lo stile di codifica che tutto il team utilizzerà.
Ciò potrebbe portare più luce sul problema:
It's important for a team to have a single coding standard for each language to avoid several problems:
- A lack of standards can make your code unreadable.
- Disagreement over standards can cause check-in wars between developers.
- Seeing different standards in the same class can be extremely irritating.
Leggi altre domande sui tag visual-studio languages internationalization