Чтоб не изобретать велосипед, решил спросить у бывалых, как проще организовать статическую (не предполагающую смены языка в процессе работы проги) интернализацию (в первом приближении, чтоб при компиляции можно было выбирать язык).
Например, если организовывать map, то как хранить ключи — строками или uid-ами (первое нагляднее, второе универсальнее и эффективнее). если uid-ами из enum-в (чтобы нагляднее было), то можно ли избавиться от дублирования его упоминания — при определении uid-а и при его связывании со строкой?
ну и т.п.
Спасибо.
Re: Простой способ статической языковой интернациализации wanted
Здравствуйте, _hum_, Вы писали:
__>Чтоб не изобретать велосипед, решил спросить у бывалых, как проще организовать статическую (не предполагающую смены языка в процессе работы проги) интернализацию (в первом приближении, чтоб при компиляции можно было выбирать язык). __>Например, если организовывать map, то как хранить ключи — строками или uid-ами (первое нагляднее, второе универсальнее и эффективнее). если uid-ами из enum-в (чтобы нагляднее было), то можно ли избавиться от дублирования его упоминания — при определении uid-а и при его связывании со строкой? __>ну и т.п.
__>Спасибо.
самый простой способ — отдельные .h файлы с #define MSG_HELLO "hello" / #define MSG_HELLO "Привет"
нужный при компиляции подключается
Re[2]: Простой способ статической языковой интернациализации wanted
Здравствуйте, wl., Вы писали:
wl.>Здравствуйте, _hum_, Вы писали:
__>>Чтоб не изобретать велосипед, решил спросить у бывалых, как проще организовать статическую (не предполагающую смены языка в процессе работы проги) интернализацию (в первом приближении, чтоб при компиляции можно было выбирать язык). __>>Например, если организовывать map, то как хранить ключи — строками или uid-ами (первое нагляднее, второе универсальнее и эффективнее). если uid-ами из enum-в (чтобы нагляднее было), то можно ли избавиться от дублирования его упоминания — при определении uid-а и при его связывании со строкой? __>>ну и т.п.
__>>Спасибо.
wl.>самый простой способ — отдельные .h файлы с #define MSG_HELLO "hello" / #define MSG_HELLO "Привет" wl.>нужный при компиляции подключается
а как же засорение пространства и опасность пересечения имен макросов строк с рабочими идентификаторами программы?
Re: Простой способ статической языковой интернациализации wanted
Здравствуйте, _hum_, Вы писали:
__>Чтоб не изобретать велосипед, решил спросить у бывалых, как проще организовать статическую (не предполагающую смены языка в процессе работы проги) интернализацию (в первом приближении, чтоб при компиляции можно было выбирать язык). __>Например, если организовывать map, то как хранить ключи — строками или uid-ами (первое нагляднее, второе универсальнее и эффективнее). если uid-ами из enum-в (чтобы нагляднее было), то можно ли избавиться от дублирования его упоминания — при определении uid-а и при его связывании со строкой? __>ну и т.п.
Файлы ресурсов: *.rc (STRINGTABLE)
Re[3]: Простой способ статической языковой интернациализации wanted
Здравствуйте, _hum_, Вы писали:
__>а как же засорение пространства и опасность пересечения имен макросов строк с рабочими идентификаторами программы?
не обязательно делать дефайны, можно делать константы
мапу логично делать для горячей смены языка. константы для статики лучше. если же еще надо форматировать текст (ну там подставлять какие-то значения), то лучше выделить функции, которые и будут делать форматирование
Re[4]: Простой способ статической языковой интернациализации wanted
Здравствуйте, uzhas, Вы писали:
U>Здравствуйте, _hum_, Вы писали:
__>>а как же засорение пространства и опасность пересечения имен макросов строк с рабочими идентификаторами программы?
U>не обязательно делать дефайны, можно делать константы U>мапу логично делать для горячей смены языка. константы для статики лучше. если же еще надо форматировать текст (ну там подставлять какие-то значения), то лучше выделить функции, которые и будут делать форматирование
константы надо два раза упоминать — при определении и при маппинге
Re[2]: Простой способ статической языковой интернациализации wanted
Здравствуйте, AlexGin, Вы писали:
AG>Здравствуйте, _hum_, Вы писали:
__>>Чтоб не изобретать велосипед, решил спросить у бывалых, как проще организовать статическую (не предполагающую смены языка в процессе работы проги) интернализацию (в первом приближении, чтоб при компиляции можно было выбирать язык). __>>Например, если организовывать map, то как хранить ключи — строками или uid-ами (первое нагляднее, второе универсальнее и эффективнее). если uid-ами из enum-в (чтобы нагляднее было), то можно ли избавиться от дублирования его упоминания — при определении uid-а и при его связывании со строкой? __>>ну и т.п. AG>Файлы ресурсов: *.rc (STRINGTABLE)
это те, что в mfc?
Re[3]: Простой способ статической языковой интернациализации wanted
Здравствуйте, _hum_, Вы писали:
__>Чтоб не изобретать велосипед, решил спросить у бывалых, как проще организовать статическую (не предполагающую смены языка в процессе работы проги) интернализацию (в первом приближении, чтоб при компиляции можно было выбирать язык). __>Например, если организовывать map, то как хранить ключи — строками или uid-ами (первое нагляднее, второе универсальнее и эффективнее). если uid-ами из enum-в (чтобы нагляднее было), то можно ли избавиться от дублирования его упоминания — при определении uid-а и при его связывании со строкой? __>ну и т.п.
Здравствуйте, _niko_.
Спасибо, интересный подход, хотя и достаточно технический.
Но я тут, по прошествие времени, пришел к выводу, что выносить все строки в отдельные таблицы — это не совсем удачное решение, поскольку перевод очень сильно зависит от контекста, а потому, по логике, придется еще и как-то информацию о контексте сохранять. Посему, принял решение делать все непосредственно в коде, наподобие:
Здравствуйте, kov_serg, Вы писали:
_>Здравствуйте, _hum_, Вы писали:
__>>Чтоб не изобретать велосипед, решил спросить у бывалых, как проще организовать статическую (не предполагающую смены языка в процессе работы проги) интернализацию (в первом приближении, чтоб при компиляции можно было выбирать язык). __>>Например, если организовывать map, то как хранить ключи — строками или uid-ами (первое нагляднее, второе универсальнее и эффективнее). если uid-ами из enum-в (чтобы нагляднее было), то можно ли избавиться от дублирования его упоминания — при определении uid-а и при его связывании со строкой? __>>ну и т.п.
_>куда проще? _>
уже же говорил — дубляж кода, и как следствие, необходимость отслеживать синхронизацию (вот затрете случайно инициализацию переменной world и все — потенциально некорректная работа интерфейса (а если это переменная, хранившая надпись для запуска ядерной ракеты, то все может кончиться печально))
Re: Простой способ статической языковой интернациализации wanted
Здравствуйте, _hum_, Вы писали:
__>Но я тут, по прошествие времени, пришел к выводу, что выносить все строки в отдельные таблицы — это не совсем удачное решение, поскольку перевод очень сильно зависит от контекста, а потому, по логике, придется еще и как-то информацию о контексте сохранять. Посему, принял решение делать все непосредственно в коде, наподобие:
Сколько у тебя кнопок "Отмена"? И как ты относишься к копипасту?
Re[3]: Простой способ статической языковой интернациализации wanted
Здравствуйте, _hum_, Вы писали:
__>Здравствуйте, kov_serg, Вы писали:
_>>Здравствуйте, _hum_, Вы писали:
__>>>Чтоб не изобретать велосипед, решил спросить у бывалых, как проще организовать статическую (не предполагающую смены языка в процессе работы проги) интернализацию (в первом приближении, чтоб при компиляции можно было выбирать язык). __>>>Например, если организовывать map, то как хранить ключи — строками или uid-ами (первое нагляднее, второе универсальнее и эффективнее). если uid-ами из enum-в (чтобы нагляднее было), то можно ли избавиться от дублирования его упоминания — при определении uid-а и при его связывании со строкой? __>>>ну и т.п.
_>>куда проще? _>>
__>уже же говорил — дубляж кода, и как следствие, необходимость отслеживать синхронизацию (вот затрете случайно инициализацию переменной world и все — потенциально некорректная работа интерфейса (а если это переменная, хранившая надпись для запуска ядерной ракеты, то все может кончиться печально))
Дублирование кода — а кто вас заставляет это делать руками?
Затрёте инициализаци — нет проблем добавим инициализацию отдельно.
Надёюсь алергии на скриптовые языки нет. Берём какой-нибудь перл:
#!/usr/bin/perl
my $name='Msg';
my $uname=uc($name);
open(my $h1, '>', "$name.h");
open(my $h2, '>', "$name-def.h");
open(my $c1, '>', "$name.cpp");
print $h1 <<TEXT
// $name.h
#pragma once
struct $name {
typedef const char* Strings;
static Strings
TEXT
;
print $h1 "\t\t";
print $h2 "// $name-def.h\n\n";
print $c1 <<TEXT
// $name.cpp
#include "$name.h"
#ifndef ${uname}_LANG_FILE
#include "$name-def.h"
#else
#include ${uname}_LANG_FILE
#endif
${name}::Strings
TEXT
;
my $comment="", $nf=0, $idx=0;
while(<DATA>) {
next if /^\s*(#|$)/;
my ($nam,$val)=/(\w+)\s+(.*)/;
if ($nf) { print $h1 ",$comment\n\t\t"; }
$idx++;
print $h1 "$nam"; $comment="\t// $idx - $val";
my $mn=uc("${name}_$nam");
print $h2 "#define $mn\t/*$idx*/\"$val\"\n";
if ($nf) { print $c1 ",\n"; }
print $c1 "/*$idx*/$name::$nam=$mn";
$nf=1;
}
print $h1 ";$comment\n};\n\n";
print $c1 ";\n\n";
close $c1;close $h2;close $h1;
__DATA__
# here strings as name value
hello hello
world world
text line1\nline2 \"1\t23\"\n
# comments