Как стимулировать скачивание локализованных версий?
Есть софтина, у которой есть языковые версии, ну и лежат они по разным URL на сайте. Когда то делал сабмит в основном английской версии, и естественно скачивают в основном аглицкую версию, ну и соотечественники наши скачивают русскую. Оно и понятно, в каталогах в основном прописана или английская версия, или русская в русских каталогах. На сайте есть раздел "Локализованные версии", но кто ж до него доходит. А гимора с этой локализацией достаточно и хотелось бы получать отдачу побольше от нее, уж коли есть немецкая версия нехай немцы ее и качают, испанцы всякие южноамериканцы — пусть свою испанскую качают.
А судя по логам сервера картина прямо с точностью до наоборот: аглицкая версия ну 250-300 скачек в день, русская примерно столько же. Все остальное немецкая, испанская — 2 скачки, 3 скачки, 5 скачек за день. А посмотришь по логам, дык видно что из Германии заходят достаточно много — во всяком случае не трое в день в день, а как минимум 30. А немцы, вообще как известно золотое дно... (ну жаба и нервничает от такого соотношения скачавшие_немецкую версию/зашедшие_немцы)
Вопрос: как побудить "шального" юзера проверить локализованные версии?
Cделал в инсталляторе ссылку "Check localized versions" — с прямой ссылкой на раздел сайта, где все локализованные версии перечислены.
Может уважаемый All, подскажет какую нить более 'интересную эффективную'идею?
Опять же часто Вы куда-нибудь ходите "из инсталлятора"? Я вот нет, разве что ради любопытства, и уж точно не имею при этом ввиду какую-либо конкретную задачу вроде поиска локализованной версии. Соответственно вряд ли пойду, а если и пойду по такой ссылке — то просто взгляну, и уйду (говорю ж, захожу скорее просто из любопытства, ради знакомства, чем с какой-то конкретной целью). А после инсталлятора, пользователю уже никак не "пойти" по этой лакомой ссылке. Всякие пункты в меню вроде "Справка\Проверить локализованные версии" ну нифига явно не работают (оно и понятно, юзеру чего-то в программе надо, задачу какую то решает — а не ссылки по меню ищет).
А то у меня немцы на втором месте по покупкам... Но.... после всех остальных вместе взятых! Уж хотелось бы им предложить локализованную версию, ну грех такую конверсию профукивать... Как бы, что называется, вот на елку то влезть? Как юзеру ясно дать понять, что "на вот мол, скачай версию на родном то языке"!?!

Здравствуйте, Carc, Вы писали:

Версия одна на всех, язык по умолчанию выбирается в зависимости от языка ОС, изменить можно в настройках.
Нафига куча разных языковых сборок? этож геморой какой

Здравствуйте, Carc, Вы писали:

C> Как юзеру ясно дать понять, что "на вот мол, скачай версию на родном то языке"!?!

а почему нельзя вынести всю локализацию с текстовик/файл ресурсов/отдельную сборку, запихать все языки в инстал, а потом пусть выбирают что хотят на месте?

ну а если нельзя — можно попытаться сделать инсталятор, который будет вытягивать нужную версию из инета (не через окно IE, которое юзеры не любят, а как отдельный шаг установки) по желанию юзера (но с предупреждением что мол инет надо).

Здравствуйте, Allix, Вы писали:

A>Здравствуйте, Carc, Вы писали:

A>Версия одна на всех, язык по умолчанию выбирается в зависимости от языка ОС, изменить можно в настройках.
А где сам язык то хранится? В Exe?
A>Нафига куча разных языковых сборок? этож геморой какой
Не сказал бы! Когда в языковой сборке 2 меню и 3 предложения у меня тоже все в одной куче лежит (exe-шник, или внешний перевод), а когда там перевода немеренно нехай живет отдельно. Переводчики по крайней мере могут спокойно работать, да и размер exe-шника сильно меньше, эдак так ощутимо в размере процентов на 50-65 для 5-то языков!?!

Здравствуйте, Niemand, Вы писали:

N>Здравствуйте, Carc, Вы писали:

C>> Как юзеру ясно дать понять, что "на вот мол, скачай версию на родном то языке"!?!

N>а почему нельзя вынести всю локализацию с текстовик/файл ресурсов/отдельную сборку, запихать все языки в инстал, а потом пусть выбирают что хотят на месте?
1) В текстовик: ну так сложилось исторически что все было в RC-файле, а не в текстовике. Теперь и сам не рад. В соседних приложениях делал как раз таки через текстовик. Гимор только поначалу, зато потом проблем не знаешь.
2) Все держать в RC: держать все 5 языков накладно по размеру, да и перевожу есессна не сам.
И потом RC определяет далеко не только перевод, но еще и структуру пользовательского — чего мне не нафиг не нужно. Я как то об этом и здесь писал, и в блоге у себя. По крайней мере первую часть статьи "Как я локализовался", коли будет время да интересующиеся (хотя бы и здесь) напишу и окончание статейки. Переводчики переводят всё в банальном текстовом файле, который вытаскивается тулзой из RC, а потом перевод заталкивается в RC обратно этой же тулзой. Таким образом мне максимум нужно корячить интерфейс только в аглицком RC — т.е. структура UI делается один раз, переводные RC создаются автоматически. + Малехо поделок и сам написал, которые на основе перевода для старой версии и нового UI, создают новую заготовку для переводчика, в которой ему нужно переводить только новые части UI, старый перевод вытаскивается из предыдущих версий.
3) Запихать все языковые exe-шники в один инсталл... Ну вроде как выход, но только
а) размер распухнет в разы.
б) ну по сути, ну нафига англичанам русский интерфейс, или немцам украинский? Понятно, что мне легче — но не уверен что это решение.
в) что действительно не гут: аглицкая версия готова сегодня, украинская завтра, немецкая через неделю, испанская только "по очень большим праздникам", когда звезды на небе расположились. Т.е. де факто нормальный полный дистритив версии X.YY.zzzz собрать не получится. Придется ждать — тормоз в развитии!

N>ну а если нельзя — можно попытаться сделать инсталятор, который будет вытягивать нужную версию из инета (не через окно IE, которое юзеры не любят, а как отдельный шаг установки) по желанию юзера (но с предупреждением что мол инет надо).
С этим конечно сложнее — NSIS такие вещи особо не умеет, а что-то кодить в нем это действительно мрачное занятие, как только пытаешься сделать нечто большее чем просто переопределить положение контролов в инсталлере и текст подсказок. Но пожалуй это тоже возможный выход. В любом случае спасибо за идею!

Здравствуйте, Carc, Вы писали:

C>1) В текстовик: ну так сложилось исторически что все было в RC-файле, а не в текстовике. Теперь и сам не рад. В соседних приложениях делал как раз таки через текстовик. Гимор только поначалу, зато потом проблем не знаешь.

А проблемы стимуляции скачивания локализованных версий — это ли не громадный гемор?
У меня одна из программ переведена на 31 язык, вот бы был гемор, если все эти языки были отдельными дистрибутивами с отдельными URL...
У меня переводы хранятся в ini-файлах — никаких проблем с переводом у добровольцев, к тому же есть бесплатные утилиты типа Ini Translator, которые еще больше процесс облегчают.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Carc, Вы писали:

C>>1) В текстовик: ну так сложилось исторически что все было в RC-файле, а не в текстовике. Теперь и сам не рад. В соседних приложениях делал как раз таки через текстовик. Гимор только поначалу, зато потом проблем не знаешь.

А>А проблемы стимуляции скачивания локализованных версий — это ли не громадный гемор?
Почему громадный? А если бы MS все свои SP со всеми языками бы положила в один большой архивчик, разве это б не "счастье" было? Вместо 3 гигов, надо скачать 50 к примеру
Разговор не по теме уже пошел.... Ну да, ну типа гемор: но у меня не 31 язык и проблемы стимуляции пользователя, по русски называется: "ссылку ему подсунуть", это вообще считайте не проблемы по сравнению с выпуском разных языковых версий. Повторюсь у меня не 20, и не 30 строк в переводе, и не 300 даже. В каждом!

А>У меня одна из программ переведена на 31 язык, вот бы был гемор, если все эти языки были отдельными дистрибутивами с отдельными URL...
Для кого гемор то? Вот приходит пользователь, выбирает версию с нужным языком и скачивает? Он что все версии подряд будет скачивать? Зачем? Или Вы сами? Или закачать проблема?
А>У меня переводы хранятся в ini-файлах — никаких проблем с переводом у добровольцев,
Аналогично. Но не для этого случая. Иконки Вы тоже будете хранить в ини-файлах?
А>к тому же есть бесплатные утилиты типа Ini Translator, которые еще больше процесс облегчают.
К тому же написать самому такую же бесплатную утилиту, и проще, и быстрее и заточить ее под свои нужды тем напильником каким нужно... Уж это то как процесс облегачает.

В общем, читаем старт топик. Если бы был возможен, ну или хоть бы приемлем выход локализации через ини, я бы так и сделал. Благо опыт есть и далеко не единственный. Но в моем случае это непримлемо по целому ряду причин, да и то если на них "забить" все равно возникнут определенные проблемы, к примеру те же "иконки" или ресурсы прошитые в код.

Здравствуйте, Carc, Вы писали:

C>Как стимулировать скачивание локализованных версий?
C>Есть софтина, у которой есть языковые версии, ну и лежат они по разным URL на сайте. Когда то делал сабмит в основном английской версии, и естественно скачивают в основном аглицкую версию, ну и соотечественники наши скачивают русскую. Оно и понятно, в каталогах в основном прописана или английская версия, или русская в русских каталогах. На сайте есть раздел "Локализованные версии", но кто ж до него доходит. А гимора с этой локализацией достаточно и хотелось бы получать отдачу побольше от нее, уж коли есть немецкая версия нехай немцы ее и качают, испанцы всякие южноамериканцы — пусть свою испанскую качают.
C>А судя по логам сервера картина прямо с точностью до наоборот: аглицкая версия ну 250-300 скачек в день, русская примерно столько же. Все остальное немецкая, испанская — 2 скачки, 3 скачки, 5 скачек за день. А посмотришь по логам, дык видно что из Германии заходят достаточно много — во всяком случае не трое в день в день, а как минимум 30. А немцы, вообще как известно золотое дно... (ну жаба и нервничает от такого соотношения скачавшие_немецкую версию/зашедшие_немцы)
C>Вопрос: как побудить "шального" юзера проверить локализованные версии?
C>Cделал в инсталляторе ссылку "Check localized versions" — с прямой ссылкой на раздел сайта, где все локализованные версии перечислены.
C>Может уважаемый All, подскажет какую нить более 'интересную эффективную'идею?
C>Опять же часто Вы куда-нибудь ходите "из инсталлятора"? Я вот нет, разве что ради любопытства, и уж точно не имею при этом ввиду какую-либо конкретную задачу вроде поиска локализованной версии. Соответственно вряд ли пойду, а если и пойду по такой ссылке — то просто взгляну, и уйду (говорю ж, захожу скорее просто из любопытства, ради знакомства, чем с какой-то конкретной целью). А после инсталлятора, пользователю уже никак не "пойти" по этой лакомой ссылке. Всякие пункты в меню вроде "Справка\Проверить локализованные версии" ну нифига явно не работают (оно и понятно, юзеру чего-то в программе надо, задачу какую то решает — а не ссылки по меню ищет).
C>А то у меня немцы на втором месте по покупкам... Но.... после всех остальных вместе взятых! Уж хотелось бы им предложить локализованную версию, ну грех такую конверсию профукивать... Как бы, что называется, вот на елку то влезть? Как юзеру ясно дать понять, что "на вот мол, скачай версию на родном то языке"!?!

Эм. Почитал. Подумал — а для кого придумано хранение ресурсов не в ехе, а в ДЛЛ? ИМХО, подход неверный изначально — по 5 версий собирать. А то, что Вы утверждаете про майкрософт — не уместно, ибо даже у них все равно все идет через ресурсы, просто количество файлов велико — вот и режут на пачки. Сборка большинства файлов, я думаю, одна. Если уж делать красиво — предлагайте скачать и ехе и пакет локализации, который, кстати, можно определить прямо на этапе выдачи странички. Либо в самой софтине сделать Изменить Язык, по которой скачивать нужный пакет, если уж у вас там и "не 300 строк". Только вот смысла особого в экономии места на ДЛЛ со строками я не вижу — если это Германия, где интернет давно не модемный. А для иконок — да, если программа подразумевает их кастомизацию ,следует делать отдельные файлы с ресурсами, имхо.

А>Эм. Почитал. Подумал — а для кого придумано хранение ресурсов не в ехе, а в ДЛЛ?
В ДЛЛ очень легко напороться на то что в ДЛЛ одна версия интерфейса, а в EXE уже другой код, который расчитан на другой UI. Причем это не то что бы "легко", а просто это уже со версии 0.00 build 2 начнется — проверено. И поймать это невозможно формальными методами (или по крайней мере весьма непросто). В DLL ресурс лежит под одним ID, а в коде обозначен другой. Причем ловить это можно только в runtime со 100% покрытием кода.
Но это еще не всё ((C) барон Мюнхаузен). Протестя одну ДЛЛ, это вообще ничего не значит с другой языковой ДЛЛ, можете начинать 100% покрытие кода в связке с другой ДЛЛ заново.
Для большого проекта, да где еще не один язык это не приемлемо. Будем без конца гонять ДЛЛ, код вообще заморозится навсегда.

А>ИМХО, подход неверный изначально — по 5 версий собирать.
Не аргументировано!
А>А то, что Вы утверждаете про майкрософт — не уместно, ибо даже у них все равно все идет через ресурсы, просто количество файлов велико — вот и режут на пачки.
Тем более не аргумент... Мало ли что там у Microsoft? У русского "Васи" тоже все через ресурсы... Газовые да нефтяные! Что? Теперь на Васю равняться?
1) "Аргумент мол Майкрософт делает, и это верно" — это вообще не аргумент. "Жираф большой ему видней" (С)
2) Если кроме шуток, у Майкрософт резоны совершенно иные для такого подхода к локализации.
а) Обьемы. При таких объемах наверное это удобно + можно держать штат переводчиков в тысячи человек.
б) Контент. Они локализуют да-а-а-леко не только, и не столько строки. А иконки, и расцветки да и вообще MS рассматривает локализацию как процесс адаптации к другим культурам, цивилизациям. Не думаю, что для проектов не MS-овского размаха, а одиночки, небольшой команды уместны такие постановки вопроса (с вытекающими затратами на выполнение такой локализации).

А> Сборка большинства файлов, я думаю, одна.
Обижаете Конечно одна — только UI в EXE-шник подпихивается для конкретного языка.
А> Если уж делать красиво — предлагайте скачать и ехе и пакет локализации, который, кстати, можно определить прямо на этапе выдачи странички.
1) Качают не с "этапа выдачи странички", а вполне реальный файл по вполне реальному URL. 99% каталогов не разрешат Вам вместо URL на скачиваемый файл ввернуть свою страничку со 33-мя предложениями. Да и пользователю это не понравится. Выбор версий одно, предложение еще и повыбирать пакеты локализации... Да уйдет пользователь с такой страницы, ничего не скачивая.
2) Я уже писал выше, что ДЛЛ это недопустимо. Ну поверьте на слово. Один из переводчиков (причем, пытливый парень — и как ему не надоело смотреть на crash с очередной версией ДЛЛ) влетел с локализацией уже на второй версии. Оказалась не та ДЛЛ, а синхронизировать версии EXE и DLL настолько четко Вы просто не сможете, не угробив на это всю оставшуюся жизнь. Рассинхронизация содержимого ДЛЛ и EXE гарантирована! Примером тому, могут быть здешние статьи на RSDN. Ни один из примеров по UI DLL в MFC за столько то лет существования статей так и не ушел дальше банальных примеров ХеллоВорлд да диалога с тремя кнопками.

А> Либо в самой софтине сделать Изменить Язык, по которой скачивать нужный пакет, если уж у вас там и "не 300 строк". Только вот смысла особого в экономии места на ДЛЛ со строками я не вижу — если это Германия, где интернет давно не модемный.
Проблема не в экономии места, а не в недостатках хранения UI в ДЛЛ.
А вот путь мне это близко — ну не вытанцовывается пока какого-то другого решения. Я пытаюсь понять когда это предлагнать пользователю?
а) в инсталлере? Имхо не лучший момент + после инсталляциии пользователь не вернется.
б) в меню? Да вроде повесил какую-то ссылку — толку ноль. Т.е. юзер там не ищет эту информацию
в) спросить его? Когда, в каком виде.
Может действительно меню верхнего уровня с названием "Язык"!?! Уж оно то будет заметно!?!

А> А для иконок — да, если программа подразумевает их кастомизацию ,следует делать отдельные файлы с ресурсами, имхо.
Ну, тут пожалуй согласен — знал бы прикуп жил бы с Сочи...
Ей богу, иногда подумываю, что нужно бы собраться да написать локализацию из ini прямо в Exe. Простую как пилорама: чтобы банально перехватывала LoadString, LoadMenu и иже с ними и локализовала их на лету. Тогда действительно язык можно вынести в отдельный файл, ну а с иконками да тулбарами можно что-нибудь да и придумать — варианты возможны.

Здравствуйте, Carc, Вы писали:

C>Здравствуйте, Allix, Вы писали:

A>>Здравствуйте, Carc, Вы писали:

A>>Версия одна на всех, язык по умолчанию выбирается в зависимости от языка ОС, изменить можно в настройках.
C>А где сам язык то хранится? В Exe?
В отдельном файле, обыный txt ключ=значение. нахрена огород то городить? Такие файлы и пользователи сами охотно переводят.

Здравствуйте, Allix, Вы писали:

A>Здравствуйте, Carc, Вы писали:

C>>Здравствуйте, Allix, Вы писали:

A>>>Здравствуйте, Carc, Вы писали:

A>>>Версия одна на всех, язык по умолчанию выбирается в зависимости от языка ОС, изменить можно в настройках.
C>>А где сам язык то хранится? В Exe?
A>В отдельном файле, обыный txt ключ=значение. нахрена огород то городить?
Написал выше — "огород уже выгороден, вспахан, и пожат не по разу". Так исторически сложилось.... Сейчас бы конечно иначе делал, хотя в тех же MFC-приложениях поддержка локализации на лету, в runtime из ini не так то просто сделать.
A>Такие файлы и пользователи сами охотно переводят.
У меня так и сделано: только не в runtime берется значение из txt ключ=значение, а design time. Все значения вытаскиваются и заталкиваются в конкретный локализованный RC, уже с которым и собирается сборка. А сам файл как раз таки понятное дело "и пользователи сами охотно переводят"... Не я же

А>>А проблемы стимуляции скачивания локализованных версий — это ли не громадный гемор?
C>Почему громадный? А если бы MS все свои SP со всеми языками бы положила в один большой архивчик, разве это б не "счастье" было? Вместо 3 гигов, надо скачать 50 к примеру

Ну если у вас софт сопоставим с софтом от MS, тогда снимаю шляпу. Мои же 31 языка перевода по тысяче строк каждый занимают в среднем по 50 КБ текста, поэтому проблемы не вижу.

А>>У меня одна из программ переведена на 31 язык, вот бы был гемор, если все эти языки были отдельными дистрибутивами с отдельными URL...
C>Для кого гемор то? Вот приходит пользователь, выбирает версию с нужным языком и скачивает? Он что все версии подряд будет скачивать? Зачем? Или Вы сами? Или закачать проблема?

Мне кажется или вы действительно не понимаете, что у меня всего ОДИН дистрибутив? И в нём все языки перевода. Зачем скачивать всё подряд? Зачем вообще выбирать — пользователи этого боятся. Должна быть одна большая ссылка "Скачать", всё. Иначе теряете пользователей. Я о домашних, правда. Возможно, у вас софт корпоративный (раз уж с MS себя сравниваете

А>>У меня переводы хранятся в ini-файлах — никаких проблем с переводом у добровольцев,
C>Аналогично. Но не для этого случая. Иконки Вы тоже будете хранить в ини-файлах?

Если бы вопрос о локализации стоял сейчас, а не несколько лет назад, то я бы для хранения языковых данных использовал бы XML файлы. Проблем с хранением иконок не вижу там.

А>>к тому же есть бесплатные утилиты типа Ini Translator, которые еще больше процесс облегчают.
C>К тому же написать самому такую же бесплатную утилиту, и проще, и быстрее и заточить ее под свои нужды тем напильником каким нужно... Уж это то как процесс облегачает.

Нда, похоже месье знает толк в извращениях Меня почти все ваши высказывания удивляют Напоминает разговор с линуксоидами — они примерно так же реагируют. Ну как может быть проще и быстрее писать свой Ini Translator, если он уже есть, бесплатный и в исходниках?

C>В общем, читаем старт топик. Если бы был возможен, ну или хоть бы приемлем выход локализации через ини, я бы так и сделал. Благо опыт есть и далеко не единственный. Но в моем случае это непримлемо по целому ряду причин, да и то если на них "забить" все равно возникнут определенные проблемы, к примеру те же "иконки" или ресурсы прошитые в код.

Ну... тут уж вам выбирать — или один раз разрешить геморрой, переделав саму систему локализации (благо языков перевода у вас пока мало), либо на протяжении жизненного цикла проекта решать вопросы о том, как же стимулировать скачивания локализованных версий

ну и постараюсь ответить по существу вопроса. Исходя из факта, что локализацию менять не будем. И исходя из получения максимума посетителей с поисковиков.

Для каждого языка перевода выделяем на сайте свой поддомен (не отдельную папку!) и там для каждого языка положить хотя бы по одной страничке, с правильным заголовком и оптимизированным под правильные ключевые слова заданного языка. Ну и ссылка на скачивание локализованной версии.
Очень бы полезно было сделать для каждой локализации свой PAD, в котором ссылки на локализованные страницы (поддомены) сайта. Продукт при этом надо конечно же по-разному называть. Идеальный вариант — продукт называть хорошей ключевой фразой на нужном языке. Это был бы очень серьезный подход к локализации, я уверен он бы работал с хорошей отдачей, но сил и средств потребует тоже — огого. Можно просто к названию продукта добавлять название языка. Например My Product Italian. Главное чтобы имена отличались. Просабмитить робософтов, что даст внешние ссылки, а следовательно и кое-какую видимость в выдаче гугла. Дальше уже проводить оптимизацию для каждого поддомена отдельно.
При заходе на главный домен, можно в зависимости от языка браузера редиректить на нужный локализованный поддомен.

Здравствуйте, Carc, Вы писали:

C>Как стимулировать скачивание локализованных версий?
C>Есть софтина, у которой есть языковые версии, ну и лежат они по разным URL на сайте. Когда то делал сабмит в основном английской версии, и естественно скачивают в основном аглицкую версию, ну и соотечественники наши скачивают русскую. Оно и понятно, в каталогах в основном прописана или английская версия, или русская в русских каталогах. На сайте есть раздел "Локализованные версии", но кто ж до него доходит. А гимора с этой локализацией достаточно и хотелось бы получать отдачу побольше от нее, уж коли есть немецкая версия нехай немцы ее и качают, испанцы всякие южноамериканцы — пусть свою испанскую качают.
C>А судя по логам сервера картина прямо с точностью до наоборот: аглицкая версия ну 250-300 скачек в день, русская примерно столько же. Все остальное немецкая, испанская — 2 скачки, 3 скачки, 5 скачек за день. А посмотришь по логам, дык видно что из Германии заходят достаточно много — во всяком случае не трое в день в день, а как минимум 30. А немцы, вообще как известно золотое дно... (ну жаба и нервничает от такого соотношения скачавшие_немецкую версию/зашедшие_немцы)
C>Вопрос: как побудить "шального" юзера проверить локализованные версии?
C>Cделал в инсталляторе ссылку "Check localized versions" — с прямой ссылкой на раздел сайта, где все локализованные версии перечислены.
C>Может уважаемый All, подскажет какую нить более 'интересную эффективную'идею?
C>Опять же часто Вы куда-нибудь ходите "из инсталлятора"? Я вот нет, разве что ради любопытства, и уж точно не имею при этом ввиду какую-либо конкретную задачу вроде поиска локализованной версии. Соответственно вряд ли пойду, а если и пойду по такой ссылке — то просто взгляну, и уйду (говорю ж, захожу скорее просто из любопытства, ради знакомства, чем с какой-то конкретной целью). А после инсталлятора, пользователю уже никак не "пойти" по этой лакомой ссылке. Всякие пункты в меню вроде "Справка\Проверить локализованные версии" ну нифига явно не работают (оно и понятно, юзеру чего-то в программе надо, задачу какую то решает — а не ссылки по меню ищет).
C>А то у меня немцы на втором месте по покупкам... Но.... после всех остальных вместе взятых! Уж хотелось бы им предложить локализованную версию, ну грех такую конверсию профукивать... Как бы, что называется, вот на елку то влезть? Как юзеру ясно дать понять, что "на вот мол, скачай версию на родном то языке"!?!

А нельзя ли на сервере определять, из какой страны зашел юзер, и в зависимости от этого выдавать ему html-страничку? Как, например, я захожу на google.com, а меня автоматом перекидывает на google.ru

Здравствуйте, jx, Вы писали:

jx>А нельзя ли на сервере определять, из какой страны зашел юзер, и в зависимости от этого выдавать ему html-страничку? Как, например, я захожу на google.com, а меня автоматом перекидывает на google.ru
Ну разве что так... Но все равно многие скачивают с файлопомоек по прямой ссылке, хотя и в этом случае можно извратиться. Эх, знал бы прикуп жил бы в Сочи
В общем, по любому получается что придется мне делать как-то в приложении. Любопытная мысль была прикрутить меню верхнего уровня (для заметности) "Язык", и оттуда пункты меню со ссылками на конкретные языковые версии. Но тоже млин вопрос: когда юзер выбирает подменю Язык он явно не очень то ждет, что начнется скачивание чего либо? Стремно А с другой стороны, гнать какого-нить испанца или немца на аглицкую страницу со списком локализованных версий... Лишний выбор, читать что там на странице написано, лишние клики — имхо тоже не будет способствовать!?!
Эх, не было у бабы забот да купила баба порося

Здравствуйте, Аноним, Вы писали:

А>Эм. Почитал. Подумал — а для кого придумано хранение ресурсов не в ехе, а в ДЛЛ? ИМХО, подход неверный изначально — по 5 версий собирать.

Что собирать по 5 версий?

Здравствуйте, Carc, Вы писали:

C>В ДЛЛ очень легко напороться на то что в ДЛЛ одна версия интерфейса, а в EXE уже другой код, который расчитан на другой UI. Причем это не то что бы "легко", а просто это уже со версии 0.00 build 2 начнется — проверено. И поймать это невозможно формальными методами (или по крайней мере весьма непросто). В DLL ресурс лежит под одним ID, а в коде обозначен другой. Причем ловить это можно только в runtime со 100% покрытием кода.

Возможно. В том числе элеменарным поиском по ID в коде. Зато когда всех переловишь, куда проще будет.

C>Но это еще не всё ((C) барон Мюнхаузен). Протестя одну ДЛЛ, это вообще ничего не значит с другой языковой ДЛЛ, можете начинать 100% покрытие кода в связке с другой ДЛЛ заново.
C>Для большого проекта, да где еще не один язык это не приемлемо. Будем без конца гонять ДЛЛ, код вообще заморозится навсегда.

Если DLL однотипные (как и должно быть), проблем не будет.

В варианте с текстовым файлом ресурсов (каким впрочем и является RC-файл) есть такая закорюка. Пусть есть диалог. На диалоге есть строки. Строки переводятся. Одна и та же строка в разных языках будет иметь разную длину. Если диалоговый ресурс один, а строка в разных вариантах перевода имеет разную длину, она попросту может не уместиться на диалоге.

Здравствуйте, jx, Вы писали:

jx>А нельзя ли на сервере определять, из какой страны зашел юзер, и в зависимости от этого выдавать ему html-страничку? Как, например, я захожу на google.com, а меня автоматом перекидывает на google.ru

толлько не это. конкретно меня это ужасно бесит (тот же гугл), я точно знаю что я хочу — обычно это english вариант...

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, jx, Вы писали:

jx>>А нельзя ли на сервере определять, из какой страны зашел юзер, и в зависимости от этого выдавать ему html-страничку? Как, например, я захожу на google.com, а меня автоматом перекидывает на google.ru

А>толлько не это. конкретно меня это ужасно бесит (тот же гугл), я точно знаю что я хочу — обычно это english вариант...
Тоже верно! "Не надо пытаться за меня думать, глупая машина!" (С)

"DenProg" <75187@users.rsdn.ru> сообщил/сообщила в новостях следующее: news:3143157@news.rsdn.ru...
> Здравствуйте, Carc, Вы писали:
>
> C>В ДЛЛ очень легко напороться на то что в ДЛЛ одна версия интерфейса, а в EXE уже другой код, который расчитан на другой UI. Причем это не то что бы "легко", а просто это уже со версии 0.00 build 2 начнется — проверено. И поймать это невозможно формальными методами (или по крайней мере весьма непросто). В DLL ресурс лежит под одним ID, а в коде обозначен другой. Причем ловить это можно только в runtime со 100% покрытием кода.
>
> Возможно. В том числе элеменарным поиском по ID в коде. Зато когда всех переловишь, куда проще будет.
Поиск по ID... О да! Я не спорю, некоторые вещи конечно можно найти, я иногда сам специально так делаю: изменить ID в resource h и все пересобрать — нехай компилятор сам трудицца, буду еще в сотнях строк искать. Тут Вы, конечно же правы. Но опишу другую вполне реальную ситуацию.
Есть у нам главное меню вида: к примеру "Вставка\Шаблоны\Сами списки_шаблонов" и подменю "Сами списки_шаблонов" формируется динамически, заполняется ну какими-либо пользовательскими шаблонами. Найти такое подменю можно ТОЛЬКО по menu pos position, т.к. у popup-меню нету никакого ID. Т.е. код будет искать по каким то магическим числа, из серии второе слева (Вставка), потом 3 сверху (Шаблоны) ну и т.д.
Понимаете кудя я клоню. Никакой поиск ID тут не поможет, его в принципе нет. Безусловно в Debug версии можно еще и ASSERTAми забить все, проверять ID соседних пунктов в меню "Вставка" — исключительно для контроля в Debug версии, что более менее в меню попали. Но все равно на этапе Икс Вы обязаны будете выбирать меню именно по позиции. Так что 100% гарантии это не даст.
Ну? Убедил? Ситуация вполне возможная (пример реальный, из живиого проекта, только немного урезал для простоты — )

> C>Но это еще не всё ((C) барон Мюнхаузен). Протестя одну ДЛЛ, это вообще ничего не значит с другой языковой ДЛЛ, можете начинать 100% покрытие кода в связке с другой ДЛЛ заново.
> C>Для большого проекта, да где еще не один язык это не приемлемо. Будем без конца гонять ДЛЛ, код вообще заморозится навсегда.
>
> Если DLL однотипные (как и должно быть), проблем не будет.
Почему не будет то? Не понял Вас... Выше описал суть:

> В варианте с текстовым файлом ресурсов (каким впрочем и является RC-файл) есть такая закорюка. Пусть есть диалог. На диалоге есть строки. Строки переводятся. Одна и та же строка в разных языках будет иметь разную длину. Если диалоговый ресурс один, а строка в разных вариантах перевода имеет разную длину, она попросту может не уместиться на диалоге.
Ну согласитесь со мной, это вполне реально и в других способах локализации. Длина строк, тут ничего не попишешь: обычно для этого предусматривается некоторый запас. Хотя есть вполне успешные проекты, где на это положили "ананас" (Total Commander, с не родным языком, + пошалить с настройками шрифтов).

Здравствуйте, DenProg, Вы писали:

DP>Здравствуйте, Аноним, Вы писали:

А>>Эм. Почитал. Подумал — а для кого придумано хранение ресурсов не в ехе, а в ДЛЛ? ИМХО, подход неверный изначально — по 5 версий собирать.

DP>Что собирать по 5 версий?
Полагаю автор имел в ввиду 5 версии ДЛЛ. Только собирать все равно 5, но проблемы с этими ДЛЛ большей частью полезут в Runtime!