Чудя се как е най-чисто да се правят текстове на различни езици (български, английски и т.н...) в сорсовете.

Проблемът е, че нямам UTF поддръжка и текстовете се очаква да са 8-bit ASCI. Когато езиците са от един код пейдж е лесно. Да кажем български и английски слагам CP1251 на сорс файла и си ги редактирам един до друг лесно в табличка, примерно:

const char bla_bla[] =
{
"Здрасти майна!", "hello mate!"
....
}

To e малко по-сложно, но идеята е че текстовете са изведени в един файл (да може да се превеждат лесно) и се виждат превода на единия език, на другия и т.н...
Но когато езиците са с различни пейджове ако единия език се чете, другия излиза на маймуняци. И което е по-лошо - не може да се редактира, поне не знам подходящ редактор. Еклипса примерно си знае за всеки код пейдж какви са допустимите символи и ако има други не иска да записва файла, сърди се...

Като гледам май ще се наложи да разхвърля всеки език на отделен файл, за да може да се редактира, обаче как да организирам така че да няма разминавания?

Правя така:
char *MAMATI_BG = "мама ти";
char *MAMATI_EN = "mama ti";
и във функцията за смяна на езика mamati = MAMATI_BG или mamati = MAMATI_EN.
Всеки език в отделен файл - много по-прегледно и по-лесно за сравняване.

абе ако имаш 1000 стринга хич не е лесно да се сравнява да ти кажа

нещо такова?
поне е стандартен метод, има тонове тулове за екстрактване, превод и т.н.
но... ако нямаш уникод, ще ти трябват 2 дисплея, или поне 2 прозореца с рзлични сетинги. на един няма как да подкараш кирилица и френски (примерно)

Аз ги слагам в отделни файлове, но също не е удобно и се случват разминавания. Имам разни предкомпилатори заради размерите, но не е достатъчно.
За в бъдеще си мисля дали с някакъв пред-процесор който да генерира няколкото файла като C сорс от друго - примерно XML или подобно. Но кирилицата е малко на заден план при мен
Другото което си мисля е да използвам структура вместо досегашните масиви. Досега индексирах през енум който трябваше да съвпада с поредността на текста. Ако вместо конкретната стойност на енума - примерно досега е било sprintf(buf, "Log:%s", EN_TEXTID_ERROR_CRC32) сега да стане sprintf(buf, "Log:%s", DEF_TEXTID_ERROR_CRC32) и да изкарам това textid като елемент от структура pstTxtIdsCurrLen->str_TEXTID_ERROR_CRC32. Може би така ще стане по-лесна инциализацията:

А за кодировките на файловете - дали няма да стане да си разпределиш езиците в отделни файлове, да кажем TextIdLangBG.h, и вътре да имаш:

и после в GlobalText.c да имаш:

Нещо подобно?

Gettext, което Дедо предлага, е най-популярната система за преводи по Линукс приложенията.
Хубавото е, че са взети предвид разни неща като различни варианти при формиране на единствено/множествено число и подобни. Има доста тулове за работа с .po файлове. Не знам до колко е подходящо при embedded системи, особено с ограничени ресурси.
Друго, което съм ползвал е QT Lingiust, което е подобно, но ползва XML формат на файловете.

Общо взето схемата на работа е следната:

Всички стрингове, които има нужда да се превеждат се прекарват през някаква функция. Примерно tr("someting something"). После има тулче, което парсва всички сорс файлове и екстрактва всички стрингове за превод в някакъв формат. Като се направят преводите с друго тулче тези фойлове се конвертират в двоичен вид (нещо подобно на хеш, или поне сортиран списък с ID-та). След приложението може да зарежда тези двоични файлове и съответно функцията tr() връща стринга преведен на избрания език.

Според моя скромен опит на Миро му трябва редактор , който да работи с
уникоде(за да може да ги вижда четими едновременно), да може да превключва различните клавиатури - бг, румъния и македония -да речем. После му трябва някакъв препроцесор (да си го напише сам) , който да вземе уникод файла и да замести кодовете с 8-битови символи, според таблиците на съответната страна.
По-вероятно е да съм написал глупости, та не се сърдете.

Добра идея е това изречение, ще взема да си го добавя към подписа. Разрешаваш ли?

OK

Всъщност Стефан най-добре е налучкал, няма какво да му се сърдим

Значи вече свсички стрингове са изнесени в един отделен текстов файл. То иначе не става, няма как да даваме на преводач всички сорсове да рови за стрингове... ъпсурд!
Като десега текстовият файл беше един, защото така е по-лесно за поддръжка. И по-лесно се превежда, щото като виждаш 2-3 езика е по-лесно да схванеш смисъла, отколкото ако виждаш само един. Даже и аз съм правел някои езици (без да ги знам) с помоща на чичко гугъл... И пускам да ми го преведе от български->френски, после го пускам от английски->френски и после сравнявам вариантите като го карам да направи обратен превод. Естествено накрая сигурно става боза (дето превели "out of sight out of mind" на японски и после го превели обратно и се получило "invisible idiot" )

Проблемът с многоезичния файл обаче е енкодинга. Трябва да е UTF, за да не ми се налага да правя собствени редактори и клавиатури както вика Стефчо. С UTF енкодинг се справят повечето редактори и всичко си е наред. Но после ми трябва да го конвертирам до ASCII, което като се замисля мога да го направя и като част от компилацията... Всъщност може и да не го конвертирам, даже си е по-редно като работя с много езици и аз да работя с UTF... Замислям се да не го направя и така, притеснява ме само че ще набъбне като размер, щото кирилицата в 1251 е 1байт, ама в UTF-8 си е два байта. И хич не са малко килобайти...
Има и друг вариант - да ползвам компресия някаква. Така даже би трябвало да се смачка повече от обикновена конверсия до ASCII. Не знам, ще го поумувам малко още...

Ами аз си мисля, че повечето редактори я имат тая функционалност.

все пак нали девелопваш на нещо лайнуксоподобно?
всички редактори, включая vi работи с уникод.

конвертиране ascii <-> уникод едва ли не и dd става (аз съм го ползвал за EBCDIC), скрипт на пърл е повече от елементарен.
на пърл е подходящо и да направиш някои анализи на честота на думи, после с речник на най-честите думи се получава доста прилична компресия. ако не стига, може да направиш и речни на изрази (комбинация от думи в речника на думи), просто много зависи от текста. в краен случай може и да се пипнат някои от съобщенията.

ако се придържаш към i18 (.po файлове), поне си на някаква територия, която вече е рутинна и много хора са копали. не говоря като крайна реализация, а като работе вариант за превод и изходен материал за компилиране на речник.

мда на лайнукс съм и нямам грижи с редактирането... По-скоро в момента имам грижи че май оставам само на лайнукс щото навремето като го инсталирах го инсталирах 32-битов. И сега след последния ъпдейт се оказа че vmplayer-а не иска да тръгва. А пък vmware деликатно са разкарали 32-битовата поддръжка и ме затрудняват
Та сега се чудя да го боря ли... дали да не си поръчавам нова машина и там да почна на чисто с 64-бит... или да заеба бозите тотално, макар че то и други неща сигурно ще спрат да бачкат на 32-бит...

Аз до колкото разбирам проблема на Миро е, че различни парчета от файлa ги иска в различни енкодинги. Примерно първо за кирилица е в 1251, после за френски 8859-1, после за китайки не знам какъв е.

Ако различните енкодинги са по блокове във файла (май не са), може преди всеки блок с различен енкодинг да слагаш някакъв маркер, примерно //*encoding: WINDOWS-1251*// и да си държлиш целия файл в utf-8. После като част от компилацията със прост скрипт и iconv си конвертираш всяко парче от utf8 на съответния енкодинг и ги събираш в един файл. То по принцип за да се визуализират тези символи правилно трябва да се знае кой език в кой енкодинг е, така че тази информация най-вероятно я имаш някъде.

Едва ли има нещо в повече тоя VMPlayer от VirtualBox, който все още има 32 bit версия.