Про локализацию здесь написано много, непонятно только одно: как это применить на практике? Например, создал я два диалога с одинаковым идентификатором и разными языками. Как вызвать тот или иной в зависимости от языка системы? Ведь внутренности DoModal мне недоступны. А как с этим обстоят дела в WTL?
Здравствуйте, 777777w, Вы писали:
7>Про локализацию здесь написано много, непонятно только одно: как это применить на практике? Например, создал я два диалога с одинаковым идентификатором и разными языками. Как вызвать тот или иной в зависимости от языка системы? Ведь внутренности DoModal мне недоступны. А как с этим обстоят дела в WTL?
Всё вовне. Чего я только не пробовал с локализациями для MFC-приложений. Те еще поделия получаются: причем геморрой безмерный и главное для всех и с оператором AND Крайне неудобно и для разработчиков, и для переводчиков UI, и для пользователей.
Ситуацию MS-овских официальных способов локализации можно описать кратко вопросом в разработчикам MS "А сами вы хоть раз этим пользовались?".
Безусловно, задачи локализации бывают очень разные. Но я бы рекомендовал сосредоточиться на главных аспектах.
— основное это строки. Все остальное — изображения, и прочая дребедень скорее исключение. Поэтому если возникнет проблема с локализацией 3-ех рисунков, не нужно париться. Три случая на весь проект тупо решаются одним костылем. Оптимизировать и упрощать работу нужно с остальными 99,99% локализуемых ресурсов. Именно она будет отнимать массу времени и сил.
— хранить локализации лучше вовне. Чтобы не плодить дистрибутивов, чтобы пользователь мог доставить локализацию.
— никаких диалогов в DLL. Лажа это. Пока диалога два — это не проблема. Как только их становиться больше пяти, начинаются косяки да баги, которые растут экспоненциально.
— строковые локализации должны легко правиться пользователями. Никакого *авна вроде таблиц Excel, и прочих форматов данных. Это все для девочек из бухгалтерии, они за это зарплату получают. Если для пользователя будет сложно переводить локализацию, он просто кладет болт на это. И никакие бесплатные лицензии не помогут.
— сразу стоит думать вперед, что локализации будут опаздывать к релизам. Соответственно логика должна быть построена так, что если нет локализованного ресурса, это ничего не ломает. Не то что там баг какой возникает — это вообще ни в какие ворота не лезет. А даже не должно быть пустого места — т.е. должно использоваться нелокализованное значение ресурса (строка на основном языке, рисунок или что там).
Здравствуйте, 777777w, Вы писали:
7>Про локализацию здесь написано много, непонятно только одно: как это применить на практике? Например, создал я два диалога с одинаковым идентификатором и разными языками. Как вызвать тот или иной в зависимости от языка системы? Ведь внутренности DoModal мне недоступны. А как с этим обстоят дела в WTL?
Зачем для каждого языка отдельный диалог?
Нужен один диалог, а строки грузить в обработчике WM_INITDIALOG через
LoadString( HINSTANCE hInstance...
где hInstance — ресурсный файл с переведенными строками.
Соответственно, если ресурсного файла для данной локали нет, то грузить дефолтные строки, которые должы быть доступны всегда.
Здравствуйте, 777777w, Вы писали:
7>Про локализацию здесь написано много, непонятно только одно: как это применить на практике? Например, создал я два диалога с одинаковым идентификатором и разными языками. Как вызвать тот или иной в зависимости от языка системы? Ведь внутренности DoModal мне недоступны. А как с этим обстоят дела в WTL?
вызвать AfxSetResourceHandle в самом начале (в InitInstance), передать в нее хэндл длл-ки с нужным языком
мфс будет вызывать ресурсы (диалоги/строки/...) из этой длл
Здравствуйте, fuyant, Вы писали:
F>Здравствуйте, 777777w, Вы писали:
7>>Про локализацию здесь написано много, непонятно только одно: как это применить на практике? Например, создал я два диалога с одинаковым идентификатором и разными языками. Как вызвать тот или иной в зависимости от языка системы? Ведь внутренности DoModal мне недоступны. А как с этим обстоят дела в WTL?
F>вызвать AfxSetResourceHandle в самом начале (в InitInstance), передать в нее хэндл длл-ки с нужным языком F>мфс будет вызывать ресурсы (диалоги/строки/...) из этой длл
НИКОГДА ТАК НЕ ДЕЛАЙТЕ!
Здравствуйте, 5er, Вы писали:
5er>Здравствуйте, 777777w, Вы писали:
7>>Про локализацию здесь написано много, непонятно только одно: как это применить на практике? Например, создал я два диалога с одинаковым идентификатором и разными языками. Как вызвать тот или иной в зависимости от языка системы? Ведь внутренности DoModal мне недоступны. А как с этим обстоят дела в WTL?
5er>Зачем для каждого языка отдельный диалог? 5er>Нужен один диалог, а строки грузить в обработчике WM_INITDIALOG через 5er>LoadString( HINSTANCE hInstance... 5er>где hInstance — ресурсный файл с переведенными строками.
5er>Соответственно, если ресурсного файла для данной локали нет, то грузить дефолтные строки, которые должы быть доступны всегда.
Дельная мысль. В точку! Только что делать когда огромная аппликуха уже написана, и диалогов в ней куча!?! Дописывать код чуть ли не с нуля, перетряхивать каждый диалог!?!
По уму — другой бы спорил — именно как Вы сказали и нужно делать. Но если б мы все были такие вумные как выпь да заранее, то багов бы и проблем и вовсе не было. Любопытственность начинается, когда все сделано, и нужно прикручивать локализацию сбоку-припеку.
Здравствуйте, 5er, Вы писали:
5er>Здравствуйте, 777777w, Вы писали:
7>>Про локализацию здесь написано много, непонятно только одно: как это применить на практике? Например, создал я два диалога с одинаковым идентификатором и разными языками. Как вызвать тот или иной в зависимости от языка системы? Ведь внутренности DoModal мне недоступны. А как с этим обстоят дела в WTL?
5er>Зачем для каждого языка отдельный диалог? 5er>Нужен один диалог, а строки грузить в обработчике WM_INITDIALOG через
PS: но ключевая мысль абсолютно правильная — не нужно отдельный диалог на отдельный язык. Это постоянный источник багов и проблем. И вообще, выражаясь "масемасисьски", нарушается правило единственного определения данных (One Definition Rule).
Здравствуйте, Carc, Вы писали:
C>Здравствуйте, fuyant, Вы писали:
F>>Здравствуйте, 777777w, Вы писали:
7>>>Про локализацию здесь написано много, непонятно только одно: как это применить на практике? Например, создал я два диалога с одинаковым идентификатором и разными языками. Как вызвать тот или иной в зависимости от языка системы? Ведь внутренности DoModal мне недоступны. А как с этим обстоят дела в WTL?
F>>вызвать AfxSetResourceHandle в самом начале (в InitInstance), передать в нее хэндл длл-ки с нужным языком F>>мфс будет вызывать ресурсы (диалоги/строки/...) из этой длл C>НИКОГДА ТАК НЕ ДЕЛАЙТЕ!
Почему?
Здравствуйте, Onorin, Вы писали:
O>Здравствуйте, Carc, Вы писали:
C>>Здравствуйте, fuyant, Вы писали:
F>>>Здравствуйте, 777777w, Вы писали:
7>>>>Про локализацию здесь написано много, непонятно только одно: как это применить на практике? Например, создал я два диалога с одинаковым идентификатором и разными языками. Как вызвать тот или иной в зависимости от языка системы? Ведь внутренности DoModal мне недоступны. А как с этим обстоят дела в WTL?
F>>>вызвать AfxSetResourceHandle в самом начале (в InitInstance), передать в нее хэндл длл-ки с нужным языком F>>>мфс будет вызывать ресурсы (диалоги/строки/...) из этой длл C>>НИКОГДА ТАК НЕ ДЕЛАЙТЕ! O>Почему?
Потому как писал уже выше
.
Рано или поздно версии диалогов в самой софтине (exe), и диалогов в DLL рассинхронизируются. В одном будет лежать одна версия, а в другом другая.
Хорошо если только бордюрчег не так прорисовываться будет, хотя "преотличнейший" на самом что ни на есть нативно-матерном языке (на том же, на котором была и версия ДЛЛ с кривым диалогом) фидбек от пользователей уже обеспечит. Дык ведь а то и баги пойдут... Эти... Они такие... Эти придут, точно!
А если учесть что у MFC есть жаркая, прямо таки мулатская страсть к конструкциям вида CWnd* pWndPointer=GetDlgItem, то в момент икс получаем нулевой указатель. Радостно по нему вызываем метод и получаем исключение нумер 5 с полным крахом софта (а ведь еще и несохраненные пользовательские данные под собой похоронит)... И вот в этот момент, матерный фидбек по форумам пойдет уже пойдет на многих языках, включая эсперанто.
И главное, убедить пользователей "что мы хотели как лучше" не получается. Им пох. И не в курсе они про наше любимое продолжение "а получилось как всегда". Им и оно пох.
Проще говоря — этот путь ведет к ошибкам. К ошибкам неприятным во многих отношениях. У одних юзеров все работает, а у других нет. Вот и гадайте в чем дело. А все почему? А совершенство, это когда нечего добавить, а не нечего убрать. Локализовать что надо было? В 99 процентов случаев это строки, строки, и только строки. Дык вот и не фиг дублировать все остальное, вроде есть кнопка, или нет, где расположена и.т.д.
И не стоит слушать MS про их "одна замечательный способ, да, через ДЛЛ лакализаваться, вай "... Нож хорош для того, у кого он окажется в нужный момент, и плох для того у кого нет (C) Абдула. В отличие от Microsoft у 99, и 9 в периоде нет ни времени, ни возможностей, ни финансов держать цельный сонм переводчиков, тестеров и прочих технических чувачков, которые будут следить за полным соответствием всех версий диалогов во всех ДЛЛ.
В общем проблем в будущем и так хватит — не стоит начинать путь софтины с заведомо потенциальных будущих геморроев.
Здравствуйте, Carc, Вы писали:
C>Здравствуйте, 777777w, Вы писали:
7>>Про локализацию здесь написано много, непонятно только одно: как это применить на практике? Например, создал я два диалога с одинаковым идентификатором и разными языками. Как вызвать тот или иной в зависимости от языка системы? Ведь внутренности DoModal мне недоступны. А как с этим обстоят дела в WTL? C>Всё вовне. Чего я только не пробовал с локализациями для MFC-приложений. Те еще поделия получаются: причем геморрой безмерный и главное для всех и с оператором AND Крайне неудобно и для разработчиков, и для переводчиков UI, и для пользователей. C>Ситуацию MS-овских официальных способов локализации можно описать кратко вопросом в разработчикам MS "А сами вы хоть раз этим пользовались?".
C>Безусловно, задачи локализации бывают очень разные. Но я бы рекомендовал сосредоточиться на главных аспектах. C>- основное это строки. Все остальное — изображения, и прочая дребедень скорее исключение. Поэтому если возникнет проблема с локализацией 3-ех рисунков, не нужно париться. Три случая на весь проект тупо решаются одним костылем. Оптимизировать и упрощать работу нужно с остальными 99,99% локализуемых ресурсов. Именно она будет отнимать массу времени и сил.
C>- хранить локализации лучше вовне. Чтобы не плодить дистрибутивов, чтобы пользователь мог доставить локализацию.
Из-за этой глупости как раз и возникают проблемы. Перевод текста с языка на язык не всегда совпадает по символьной длине и количеству строк. И диалоги будут выглядеть не красиво.
C>- никаких диалогов в DLL. Лажа это. Пока диалога два — это не проблема. Как только их становиться больше пяти, начинаются косяки да баги, которые растут экспоненциально.
Где вы предлагаете хранить диалоги? Их как раз и нужно хранить в разных DLL-ках. Это как раз и избавит от проблем с "опаздывающий локализацией".
C>- строковые локализации должны легко правиться пользователями. Никакого *авна вроде таблиц Excel, и прочих форматов данных. Это все для девочек из бухгалтерии, они за это зарплату получают. Если для пользователя будет сложно переводить локализацию, он просто кладет болт на это. И никакие бесплатные лицензии не помогут.
Строковые локализации никогда не должны правится пользователем.
C>- сразу стоит думать вперед, что локализации будут опаздывать к релизам. Соответственно логика должна быть построена так, что если нет локализованного ресурса, это ничего не ломает. Не то что там баг какой возникает — это вообще ни в какие ворота не лезет. А даже не должно быть пустого места — т.е. должно использоваться нелокализованное значение ресурса (строка на основном языке, рисунок или что там).
C>Это основное. Детали зависят от задач.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Carc, Вы писали:
C>>Здравствуйте, 777777w, Вы писали:
7>>>Про локализацию здесь написано много, непонятно только одно: как это применить на практике? Например, создал я два диалога с одинаковым идентификатором и разными языками. Как вызвать тот или иной в зависимости от языка системы? Ведь внутренности DoModal мне недоступны. А как с этим обстоят дела в WTL? C>>Всё вовне. Чего я только не пробовал с локализациями для MFC-приложений. Те еще поделия получаются: причем геморрой безмерный и главное для всех и с оператором AND Крайне неудобно и для разработчиков, и для переводчиков UI, и для пользователей. C>>Ситуацию MS-овских официальных способов локализации можно описать кратко вопросом в разработчикам MS "А сами вы хоть раз этим пользовались?".
C>>Безусловно, задачи локализации бывают очень разные. Но я бы рекомендовал сосредоточиться на главных аспектах. C>>- основное это строки. Все остальное — изображения, и прочая дребедень скорее исключение. Поэтому если возникнет проблема с локализацией 3-ех рисунков, не нужно париться. Три случая на весь проект тупо решаются одним костылем. Оптимизировать и упрощать работу нужно с остальными 99,99% локализуемых ресурсов. Именно она будет отнимать массу времени и сил.
C>>- хранить локализации лучше вовне. Чтобы не плодить дистрибутивов, чтобы пользователь мог доставить локализацию. А>Из-за этой глупости как раз и возникают проблемы. Перевод текста с языка на язык не всегда совпадает по символьной длине и количеству строк. И диалоги будут выглядеть не красиво.
Глупости. Некрасиво выглядящие диалоги связаны с кривизной рук, и угловым схождением глаз. Если про сферического коня в вакууме. А если конкретно про MFC, то там о таких вещах нужно думать вперед.
C>>- никаких диалогов в DLL. Лажа это. Пока диалога два — это не проблема. Как только их становиться больше пяти, начинаются косяки да баги, которые растут экспоненциально. А>Где вы предлагаете хранить диалоги? Их как раз и нужно хранить в разных DLL-ках. Это как раз и избавит от проблем с "опаздывающий локализацией".
Нет, не избавит. Проблема запаздывания локализации связана не хранением, или нехранением диалогов в DLL или где-бы то ни было. Причина запаздывания в самой сути коллективной работы.
А вот хранение диалогов во внешних DLL приводит к тому в большинстве случаев что откуда-ни-возьмись таки появляются разные версии диалогов. А это ведет к очень трудноуловимым багам. Причем не по самой технической сути бага — они то как раз будут что ни на есть тривиальные. А в том, что о возникновении бага можно, ну очень долго вообще и не подозревать, т.к. он будет проявляться в конкретном месте, при конкретных сочетаниях условий, у конкретных пользователей. И только уже поэтому баг будет жить ну очень долго.
Вам просто даже никто и не сообщит о проблеме. Упала аппликуха и упала. А и гуй с ним. Uninstall и до свиданья. Это практика, печальная — но она такова. Другое дело, что под концепции боксеров-теоретиков она плохо подходит: ибо "некрасиво", ибо "избавит от проблем". Не важно насколько красивый диалог, если пользователь его даже не увидит. А после анисталла он его точно не увидит.
C>>- строковые локализации должны легко правиться пользователями. Никакого *авна вроде таблиц Excel, и прочих форматов данных. Это все для девочек из бухгалтерии, они за это зарплату получают. Если для пользователя будет сложно переводить локализацию, он просто кладет болт на это. И никакие бесплатные лицензии не помогут. А>Строковые локализации никогда не должны правится пользователем.
Чушь. Продвигаемая агенствами переводчиков. Вменяемый нейтив делает преотличнейший перевод.
Никто и не говорит, что пользователя надо обязывать делать перевод. Или обязательно его включать. Но дать ему возможность сделать это за лицензию, имеет смысл. Можно получить отличный результат. В конце концов включать конкретную локализацию в официальный дистрибутив или нет — решение за разработчиками.
Здравствуйте, 777777w, Вы писали:
7>Про локализацию здесь написано много, непонятно только одно: как это применить на практике? Например, создал я два диалога с одинаковым идентификатором и разными языками. Как вызвать тот или иной в зависимости от языка системы? Ведь внутренности DoModal мне недоступны. А как с этим обстоят дела в WTL?
Используйте утилиту langagent (http://langagent.com)
Таким макаром локализована утилита hddlife
>> В общем проблем в будущем и так хватит — не стоит начинать путь софтины с >> заведомо потенциальных будущих геморроев.
MZ>Это всё хорошо, только есть одно НО. MZ>Строки на английском языке имеют одну длину, строки на русском другую, MZ>а стоки на немецком -- третью. MZ>Оно просто тупо НЕВЛЕЗЕТ. MZ>Кстати, в интерфейсе андроида сделано именно так всё. Случаев, когда MZ>невлазит, дофига. Правда, достаточно всё терпимо.
Офигеть какое новость! Малыш, ты не поверишь, оно все-таки не влезает... Прям открытие 2012-го года
А Вы что-нибудь слышали про то, что UI принято тестировать? Ну хотя бы банально проверить, а оно вообще как выглядит!?!
Здравствуйте, Carc, Вы писали:
C>Здравствуйте, 5er, Вы писали:
5er>>Здравствуйте, 777777w, Вы писали:
7>>>Про локализацию здесь написано много, непонятно только одно: как это применить на практике? Например, создал я два диалога с одинаковым идентификатором и разными языками. Как вызвать тот или иной в зависимости от языка системы? Ведь внутренности DoModal мне недоступны. А как с этим обстоят дела в WTL?
5er>>Зачем для каждого языка отдельный диалог? 5er>>Нужен один диалог, а строки грузить в обработчике WM_INITDIALOG через 5er>>LoadString( HINSTANCE hInstance... 5er>>где hInstance — ресурсный файл с переведенными строками.
5er>>Соответственно, если ресурсного файла для данной локали нет, то грузить дефолтные строки, которые должы быть доступны всегда. C>Дельная мысль. В точку! Только что делать когда огромная аппликуха уже написана, и диалогов в ней куча!?! Дописывать код чуть ли не с нуля, перетряхивать каждый диалог!?! C>По уму — другой бы спорил — именно как Вы сказали и нужно делать. Но если б мы все были такие вумные как выпь да заранее, то багов бы и проблем и вовсе не было. Любопытственность начинается, когда все сделано, и нужно прикручивать локализацию сбоку-припеку.
Если приложение уже написано, то:
— берем диалог
— выделяем все строки
— делаем транслятор типа Qt'шного tr.
Здесь же организуем корректировку по длине и прочую логику типа выбора локали и подгрузку ресурса с переведенными строками.
Здесь же фактически сидит глобальный мап IDS->текст, чтобы лишний раз не дергать API
— далее при создании диалога инициализируем в нем каждую строчку, вот так без дураков строчка
за строчкой: tr(IDS_N), tr(IDS_N+1)...
Если какую забыли, не беда — в диалоге уже сидит дефолтная (приложение же уже написано), потом поправим
— на 3-4-м диалоге доходим да всех нюансов и далее просто рутина.
Здравствуйте, 5er, Вы писали:
5er>Здравствуйте, Carc, Вы писали:
C>>Здравствуйте, 5er, Вы писали:
5er>>>Здравствуйте, 777777w, Вы писали:
7>>>>Про локализацию здесь написано много, непонятно только одно: как это применить на практике? Например, создал я два диалога с одинаковым идентификатором и разными языками. Как вызвать тот или иной в зависимости от языка системы? Ведь внутренности DoModal мне недоступны. А как с этим обстоят дела в WTL?
5er>>>Зачем для каждого языка отдельный диалог? 5er>>>Нужен один диалог, а строки грузить в обработчике WM_INITDIALOG через 5er>>>LoadString( HINSTANCE hInstance... 5er>>>где hInstance — ресурсный файл с переведенными строками.
5er>>>Соответственно, если ресурсного файла для данной локали нет, то грузить дефолтные строки, которые должы быть доступны всегда. C>>Дельная мысль. В точку! Только что делать когда огромная аппликуха уже написана, и диалогов в ней куча!?! Дописывать код чуть ли не с нуля, перетряхивать каждый диалог!?! C>>По уму — другой бы спорил — именно как Вы сказали и нужно делать. Но если б мы все были такие вумные как выпь да заранее, то багов бы и проблем и вовсе не было. Любопытственность начинается, когда все сделано, и нужно прикручивать локализацию сбоку-припеку.
5er>Если приложение уже написано, то: 5er>- берем диалог 5er>- выделяем все строки 5er>- делаем транслятор типа Qt'шного tr. 5er>Здесь же организуем корректировку по длине и прочую логику типа выбора локали и подгрузку ресурса с переведенными строками. 5er>Здесь же фактически сидит глобальный мап IDS->текст, чтобы лишний раз не дергать API 5er>- далее при создании диалога инициализируем в нем каждую строчку, вот так без дураков строчка 5er>за строчкой: tr(IDS_N), tr(IDS_N+1)... 5er>Если какую забыли, не беда — в диалоге уже сидит дефолтная (приложение же уже написано), потом поправим 5er>- на 3-4-м диалоге доходим да всех нюансов и далее просто рутина.
А если не только диалоги!?! А если меню? А если окна? А если строки?
Что-то я сомневаюсь, что обойдется все вот такой вот централизацией загрузки диалогов.
Хотя, к слову говоря, отчасти теперь я в большинстве новых проектов всегда завожу какой-нить базовый диалог что-то вроде CMySuperAppDialog, от которого наследуются уже все фактические. Это решает проблему (хотя и потянуло на эти рюшечки не из-за локализации, а из-за поддержки тем UI, но и локализацию тут не сложно прикрутить).
... 5er>>- далее при создании диалога инициализируем в нем каждую строчку, вот так без дураков строчка 5er>>за строчкой: tr(IDS_N), tr(IDS_N+1)... 5er>>Если какую забыли, не беда — в диалоге уже сидит дефолтная (приложение же уже написано), потом поправим 5er>>- на 3-4-м диалоге доходим да всех нюансов и далее просто рутина. C>А если не только диалоги!?! А если меню? А если окна? А если строки? C>Что-то я сомневаюсь, что обойдется все вот такой вот централизацией загрузки диалогов.
Локализация касается только строк.
Даже если есть надпись на битмапе, по хорошему ее нужно рисовать из IDS.
А вставляются ли эти строки в меню или в левый угол окна не суть важно.
Важно, чтобы был IDS строки и место, где известно как и куда ее вывести.
Пока писал, у меня вопрос созрел. А все-таки есть ли ситуации, когда нужны два и более диалога.
Например, кнопки располагаются в порядке OK Cancel, для любой локали.
А где-то, к примеру, принят порядок Cancеl OK.
По идее нужно рисовать отдельный диалог. Но примеров из реальной жизни не припоминаю.
Или не диалог, а меню или порядок столбцов в листе, могут ли зависеть от локали?
C>Хотя, к слову говоря, отчасти теперь я в большинстве новых проектов всегда завожу какой-нить базовый диалог что-то вроде CMySuperAppDialog, от которого наследуются уже все фактические. Это решает проблему (хотя и потянуло на эти рюшечки не из-за локализации, а из-за поддержки тем UI, но и локализацию тут не сложно прикрутить).
Здравствуйте, 5er, Вы писали:
5er>Здравствуйте, Carc, Вы писали:
5er>Пока писал, у меня вопрос созрел. А все-таки есть ли ситуации, когда нужны два и более диалога. 5er>Например, кнопки располагаются в порядке OK Cancel, для любой локали. 5er>А где-то, к примеру, принят порядок Cancеl OK. 5er>По идее нужно рисовать отдельный диалог. Но примеров из реальной жизни не припоминаю. 5er>Или не диалог, а меню или порядок столбцов в листе, могут ли зависеть от локали?
В японском языке часто бывают проблемы, из-за того, что у них нестандартный размер шрифта.
Обычно у диалогов используется фонт "MS Shell Dlg", который имеет логический размер.
Реальный же размер зависит от локализации.
Это очень неприятно, когда реализуешь плагин, в котором твои окна встраиваются в окна другого приложения,
т.е имеются ограничения на размер окон плагина.
Здравствуйте, 5er, Вы писали:
5er>Здравствуйте, Carc, Вы писали:
5er>... 5er>>>- далее при создании диалога инициализируем в нем каждую строчку, вот так без дураков строчка 5er>>>за строчкой: tr(IDS_N), tr(IDS_N+1)... 5er>>>Если какую забыли, не беда — в диалоге уже сидит дефолтная (приложение же уже написано), потом поправим 5er>>>- на 3-4-м диалоге доходим да всех нюансов и далее просто рутина. C>>А если не только диалоги!?! А если меню? А если окна? А если строки? C>>Что-то я сомневаюсь, что обойдется все вот такой вот централизацией загрузки диалогов.
5er>Локализация касается только строк. 5er>Даже если есть надпись на битмапе, по хорошему ее нужно рисовать из IDS. 5er>А вставляются ли эти строки в меню или в левый угол окна не суть важно. 5er>Важно, чтобы был IDS строки и место, где известно как и куда ее вывести.
5er>Пока писал, у меня вопрос созрел. А все-таки есть ли ситуации, когда нужны два и более диалога. 5er>Например, кнопки располагаются в порядке OK Cancel, для любой локали. 5er>А где-то, к примеру, принят порядок Cancеl OK. 5er>По идее нужно рисовать отдельный диалог. Но примеров из реальной жизни не припоминаю.
Внимательно, внимательно читаем Макконнелла, Фредерика Брукса — и ищем упоминание славной мысли
"Программист берет один случай из миллиона и бесконечно оптимизирует его до тех пор пока все окончательно не сломается"
Да поймите Вы наконец. Есть правильно 90\10. И то что для нас занимает 90 процентов времени, это те самые 10 процентов программы. Понятно, что нам дюже нравится до бесконечности оптимизировать тот самый 1 случай из миллиона. Это и есть наша профессия, наша работа, наше всё. Потому как остальные 999 999 случаев неинтересны, они выполняются автоматически (кодом, компилятором, кодогенератором и.т.д.).
Но в реальной жизни все с точностью до наоборот. Пользователь будет иметь 90 процентов времени дело с 90 процентами Вашего кода. В том числе и с изысками по локализации. Поверьте, ему будет абсолютно *асрать на порядок кнопок, потому как в остальных 90 процентов был допущен пусть маленький, но косяк. Зато который проявляется все 90 процентов времени работы, и постоянно мешают этому же пользователю.
Не то, не то оптимизируете. Более того, мне совсем не нравится идея перетряхивать все диалоги, и переписывать всю инициализацию строк. Угадайте почему? А как раз потому, что те самые 90 процентов рутинной работы, которые нам с Вами неинтересны. Но главное: это явно не лезет ни в какие ворота — чтобы кто-то лез в код отлаженного диалога, и только из-за какой-то локализации влиял на логику работы. А такие изменения как преждевременная инициализация — это достаточное изменение, чтобы где-нибудь до сломалось.
Такие вещи нужно делать через аспектное программирование. Да и вообще подход из серии "переписать всё нафиг" оставим для школьничков. У них аккурат скоро юбилей — первая тыща строк за плечами. Не грех и переписать нафиг. А в реальном, отлаженном, работающем на пользователя проекте с сотнями тысяч строк это не пойдет. Да вас просто не подпустят к коду (и правильно сделают).
Ладно заканчиваем холивар. Пошли знакомые школьнически-академические мысли я смотрю. Предлагаемые решения "переписать" идеальны и мерцают в ночи, восхищая своей гармонией. Так бывает на бумаге, да забыли про овраги. В реальных проектах эти решения не работают.
PS: не надо только про QT — как идеал, и пример для подражания. Убожество ее архитектуры потрясло меня до основания... Изначально предлагать чуть ли не всё и вся инициализировать в main, как общий подход — это что-то. Иногда и так надо, иногда в начале поиска решения — ну куда деваться. Но к 2012-му году на что-то претендовать в архитектурном смысле слова это ей богу даже не смешно.
Здравствуйте, baily, Вы писали:
B>Здравствуйте, 5er, Вы писали:
5er>>Здравствуйте, Carc, Вы писали:
5er>>Пока писал, у меня вопрос созрел. А все-таки есть ли ситуации, когда нужны два и более диалога. 5er>>Например, кнопки располагаются в порядке OK Cancel, для любой локали. 5er>>А где-то, к примеру, принят порядок Cancеl OK. 5er>>По идее нужно рисовать отдельный диалог. Но примеров из реальной жизни не припоминаю. 5er>>Или не диалог, а меню или порядок столбцов в листе, могут ли зависеть от локали?
B>В японском языке часто бывают проблемы, из-за того, что у них нестандартный размер шрифта. B>Обычно у диалогов используется фонт "MS Shell Dlg", который имеет логический размер. B>Реальный же размер зависит от локализации.
B>Это очень неприятно, когда реализуешь плагин, в котором твои окна встраиваются в окна другого приложения, B>т.е имеются ограничения на размер окон плагина.
А посмотрите на плагины FAR... У него локализация это часть Plugin API, чтобы ни кто во что горазд оттягивался. И действительно, хост-приложению явно будет больше известно о всех потенциальных проблемах, чем конкретному плагину, в том числе и о проблемах локализации.
Крайне неудобно и для разработчиков, и для переводчиков UI, и для пользователей.
Только что делать когда огромная аппликуха уже написана, и диалогов в ней куча!?! Дописывать код чуть ли не с нуля, перетряхивать каждый диалог!?! 
Прям открытие 2012-го года 
