2

I'm a member of a small new team and with one of our latest builds I noted that, VS2010 code files don't contain language formatting.

So for example when I write down a Euro symbol in my code or use a "." or "," in numbers or use Pounds, Euro or Dollar symbols, those look ok in my code, but for a coder in Russia they don't. I wonder how other people tackle these kind of problems?

gnat
  • 21,442
  • 29
  • 112
  • 288
user613326
  • 571
  • 8
  • 19
  • Decide on the language and Visual Studio settings you want to use for the project. – Bernard Apr 19 '13 at 00:37
  • possible duplicate of [Internationalization : What things to think about?](http://programmers.stackexchange.com/questions/87452/internationalization-what-things-to-think-about) – gnat Apr 19 '13 at 07:49
  • 1
    possible duplicate of [How should I architect multi-language support for a group of applications?](http://programmers.stackexchange.com/questions/146898/how-should-i-architect-multi-language-support-for-a-group-of-applications) –  Apr 19 '13 at 11:30
  • 1
    user613326, please read over the questions in the [tag:internationalization] tag (hint, you can click through on the tag to get a listing); many of the broader questions you are asking have already been resolved in there. After reviewing those and you still have an unanswered question, please feel free to call out the nuance between your question and what's been already asked. –  Apr 19 '13 at 11:32
  • Ok i didnt knew such tag, but the answer didnt had an answer as sugested, the answer i was looking for was givven by Jan Hudec its the utf part that he explains. ..still one needs to be carefull dough with font selections, but this is what i was looking for. – user613326 Apr 20 '13 at 14:54
  • This does not seem to be a duplicate of either of the suggested questions. This is about IDE configuration while those are about i18n of applications. – Rein Henrichs Apr 25 '13 at 16:18
  • I agree, this is about how to make sure the developers' IDEs share the same language settings. – Michael Brown Apr 26 '13 at 14:37

2 Answers2

3

One solution is to have a document that outlines the coding style that all in the team will be using.

This could bring more light on the issue:

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.

Does your company have a coding standard?

Community
  • 1
jsedano
  • 440
  • 2
  • 14
  • well we have some standard but since we freelance besides our team, visual studio settings country settings all need to change, and sometimes people forget that and.. we get into coding problems. So i hoped that language of the code files could be set somewhere in the project.. – user613326 Apr 18 '13 at 23:15
  • @user613326: Encoding problems are best solved with unicode (see my answer). For other issues, coding guidelines are needed. Usually in multi-national company the coding guidelines should say that both symbol names and comments must be in English. – Jan Hudec Apr 19 '13 at 08:13
3

Non-ascii characters are pain in Visual Studio. While our team does not consist of people using different locales, we have occasional need for characters from different locales and we use several other compilers that behave differently. So here is what we found works:

  • Visual Studio recognizes UTF-8 byte order mark. You can change the encoding in "File/Advanced Save Options" for individual file and default somewhere in Options. If you choose Unicode (UTF-8 with signature) - Codepage 65001, it is going to always display the same to all team members.
  • Unicode characters in wide literals (L"...") are properly encoded in UTF-8 sources.
  • Unicode characters in narrow literals ("...") are recoded to local charset. Without ability to select which one you want to recode to. So it will be recoded differently when different people compile it. Utterly useless; though I am not sure it is still not possible in VS2010, we use VS2008 and there it is not possible.
  • Escape sequences are never recoded.

So use the UTF-8 to make files display correctly for everybody, but in narrow strings you have to always use escapes anyway. You may use the characters directly in wide literals, but if you ever need to port the code, using escape sequences there is preferred anyway. It's not readable, yes. You can have the actual text in comment, it will display fine if it is UTF-8.

Hm, that was in particular for encoding, which I know is can of worms in Visual Studio. For the other things, in comments you just use one common language, usually English. And in user output you have to use std::locale.

As for actual localization, the resources system by default provided by Microsoft toolchain is notoriously difficult to maintain. I strongly recommend using system, that has English literals directly in code and translation catalogues from English to the other language. This ensures that you don't forget to update the translations when the source changes.

Either use Gettext, which can now be read by Boost.Locale or similar framework (e.g. Qt has similar system built in (and KDE replaces it with Gettext anyway)).

Boost.Locale also provides some function that make use of std::locale more convenient. Mainly extended typesafe printf-like function extended to support calling the std::locale number/currency/date... formatters internally.

Jan Hudec
  • 18,250
  • 1
  • 39
  • 62
  • Good advice -- only caveat is if you need to support asian language characters its actually more efficient to go for UTF16 as most asian characters take up three or four bytes in UTF8. – James Anderson Apr 19 '13 at 08:37
  • @JamesAnderson: Unicode Basic Multilingual Plane fits in three bytes in UTF-8 and anything beyond needs four bytes in UTF-16 anyway. So the saving is 1/3 at most and only applies to blocks of asian text. For application that is not specific to Asian cultural area, rarely worth the trouble. And C++ sources in particular will always contain more ascii, so never true for those; besides many compilers won't accept UTF-16 source. – Jan Hudec Apr 19 '13 at 09:05