Здравствуйте, Carc, Вы писали:
C> Как юзеру ясно дать понять, что "на вот мол, скачай версию на родном то языке"!?!
а почему нельзя вынести всю локализацию с текстовик/файл ресурсов/отдельную сборку, запихать все языки в инстал, а потом пусть выбирают что хотят на месте?
ну а если нельзя — можно попытаться сделать инсталятор, который будет вытягивать нужную версию из инета (не через окно IE, которое юзеры не любят, а как отдельный шаг установки) по желанию юзера (но с предупреждением что мол инет надо).
If the message above is in English — means I'm wasting my work time and work computer to post here. No hard feelings
Здравствуйте, Carc, Вы писали:
C>Ну разве что так... Но все равно многие скачивают с файлопомоек по прямой ссылке, хотя и в этом случае можно извратиться.
Пряма ссылка элементарно редиректится на скрипт, который уже может определять страну...
еще варианты.
1. веб инсталлер, например как у гугл хрома
2. нормальный инсталер, но при запуске проверяется язык системы и если есть локализованная под этот язык, говорим об этом пользователю (на его языке) и настойчиво советуем пойти скачать, разумеется с возможностью поставить инг.
3. пункт меню в проге — обновится до локализованной версии (с автоматической скачкой\установкой)
B_>> 1. веб инсталлер, например как у гугл хрома C>Стремно, прога не для сети. Хотя тоже вариант. Минусы: если он сразу из инсталлера не пойдет, а и по разным причинам: некогда, хочет быстро посмотреть, хочет проверить именно эту версию, то потом он уже не вернется к инсталлеру. А это имхо важный момент: если юзер все таки пользуется, то собственно ему по идее то локализованная версия и нужна. А к инсталлеру он не возвращается, ибо поставил и пользуется.
Согласен.
B_>> 2. нормальный инсталер, но при запуске проверяется язык системы и если есть локализованная под этот язык, говорим об этом пользователю (на его языке) и настойчиво советуем пойти скачать, разумеется с возможностью поставить инг. C>Суть имхо та же что и в п.1. Может проще на первой странице инсталлера показывать прямые ссылки на локализованные версии? Минусы те же: + народ привык к инсталлерам, многие просто быстро кликают на Next, не особо разглядывая.
На первой странице радио кнопки
* поставить эту английскую
* Скачать и поставить локализованную на ваш (подставить) язык (займет 3 минуты)
* Скачать и поставить локализованную на...
* Скачать и поставить локализованную на...
* Скачать и поставить локализованную на...
По умолчанию не выбран не один вариант. Как минимум пользователь остановится и прочтет. И если лень, просто тыкнет в английскую и поставит быстро, то есть шанс потерять пользователя минимален.
B_>> 3. пункт меню в проге — обновится до локализованной версии (с автоматической скачкой\установкой) C>Не мастер я в этом, к сожалению. Боюсь нормальный use case, usability такого решения я сделаю дай бог раза с 30-го (к тому моменту все забьют на эту возможность окончательно). C>Может быть действительно просто сделать меню "Язык" в программе и оттуда прямые ссылки на локализованные версии. C>Плюсы: зато URL откроется в браузере и в целом все подконтрольно пользователю: он знает что и куда он скачал, куда поставил!?! C>К примеру, если сделать меню "Язык" на верхнем уровне, пункт в главном меню — то не заметить его будет сложно — внимание привлечь вроде должно получиться. C>Минусы: кто ожидает от меню "Язык" похода за скачкой? Неожиданное поведение. Правда, тут я как раз могу выйти из проблемы — у меня к каждому пункту меню рядом "ползает" подсказка чего делает меню, причем написана она по человечески, с советами, рекомендациями, и действительно со смысловой нагрузкой. В такой подсказке можно писать что начнется скачка локализованной версии по прямой ссылке!?!
KISS...
Меню язык. При выборе пункта меню, мессадж бокс, который обьясняет что вот как раз для этого языка, к сожалению, надо скачать новый инсталлер с сайта.. Хотите закрыть программу и открыть локализованную страницу сайта ? да\нет.
Здравствуйте, 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
Как стимулировать скачивание локализованных версий?
Есть софтина, у которой есть языковые версии, ну и лежат они по разным URL на сайте. Когда то делал сабмит в основном английской версии, и естественно скачивают в основном аглицкую версию, ну и соотечественники наши скачивают русскую. Оно и понятно, в каталогах в основном прописана или английская версия, или русская в русских каталогах. На сайте есть раздел "Локализованные версии", но кто ж до него доходит. А гимора с этой локализацией достаточно и хотелось бы получать отдачу побольше от нее, уж коли есть немецкая версия нехай немцы ее и качают, испанцы всякие южноамериканцы — пусть свою испанскую качают.
А судя по логам сервера картина прямо с точностью до наоборот: аглицкая версия ну 250-300 скачек в день, русская примерно столько же. Все остальное немецкая, испанская — 2 скачки, 3 скачки, 5 скачек за день. А посмотришь по логам, дык видно что из Германии заходят достаточно много — во всяком случае не трое в день в день, а как минимум 30. А немцы, вообще как известно золотое дно... (ну жаба и нервничает от такого соотношения скачавшие_немецкую версию/зашедшие_немцы) Вопрос: как побудить "шального" юзера проверить локализованные версии? Cделал в инсталляторе ссылку "Check localized versions" — с прямой ссылкой на раздел сайта, где все локализованные версии перечислены.
Может уважаемый All, подскажет какую нить более 'интересную эффективную'идею?
Опять же часто Вы куда-нибудь ходите "из инсталлятора"? Я вот нет, разве что ради любопытства, и уж точно не имею при этом ввиду какую-либо конкретную задачу вроде поиска локализованной версии. Соответственно вряд ли пойду, а если и пойду по такой ссылке — то просто взгляну, и уйду (говорю ж, захожу скорее просто из любопытства, ради знакомства, чем с какой-то конкретной целью). А после инсталлятора, пользователю уже никак не "пойти" по этой лакомой ссылке. Всякие пункты в меню вроде "Справка\Проверить локализованные версии" ну нифига явно не работают (оно и понятно, юзеру чего-то в программе надо, задачу какую то решает — а не ссылки по меню ищет).
А то у меня немцы на втором месте по покупкам... Но.... после всех остальных вместе взятых! Уж хотелось бы им предложить локализованную версию, ну грех такую конверсию профукивать... Как бы, что называется, вот на елку то влезть? Как юзеру ясно дать понять, что "на вот мол, скачай версию на родном то языке"!?!
Версия одна на всех, язык по умолчанию выбирается в зависимости от языка ОС, изменить можно в настройках.
Нафига куча разных языковых сборок? этож геморой какой
Здравствуйте, 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. Главное чтобы имена отличались. Просабмитить робософтов, что даст внешние ссылки, а следовательно и кое-какую видимость в выдаче гугла. Дальше уже проводить оптимизацию для каждого поддомена отдельно.
При заходе на главный домен, можно в зависимости от языка браузера редиректить на нужный локализованный поддомен.
Здравствуйте, jx, Вы писали:
jx>А нельзя ли на сервере определять, из какой страны зашел юзер, и в зависимости от этого выдавать ему html-страничку? Как, например, я захожу на google.com, а меня автоматом перекидывает на google.ru
Ну разве что так... Но все равно многие скачивают с файлопомоек по прямой ссылке, хотя и в этом случае можно извратиться. Эх, знал бы прикуп жил бы в Сочи
В общем, по любому получается что придется мне делать как-то в приложении. Любопытная мысль была прикрутить меню верхнего уровня (для заметности) "Язык", и оттуда пункты меню со ссылками на конкретные языковые версии. Но тоже млин вопрос: когда юзер выбирает подменю Язык он явно не очень то ждет, что начнется скачивание чего либо? Стремно А с другой стороны, гнать какого-нить испанца или немца на аглицкую страницу со списком локализованных версий... Лишний выбор, читать что там на странице написано, лишние клики — имхо тоже не будет способствовать!?!
Эх, не было у бабы забот да купила баба порося
Здравствуйте, Аноним, Вы писали:
А>Эм. Почитал. Подумал — а для кого придумано хранение ресурсов не в ехе, а в ДЛЛ? ИМХО, подход неверный изначально — по 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!
Здравствуйте, Аноним, Вы писали:
А>Ну если у вас софт сопоставим с софтом от MS, тогда снимаю шляпу. Мои же 31 языка перевода по тысяче строк каждый занимают в среднем по 50 КБ текста, поэтому проблемы не вижу.
1) Отклоняемся от темы... Если бы Вы перечитали этот мой пост
, то увидели что я как раз таки не сравниваю себе с MS, а противопоставляю по вполне обьективно существующим причинам.
2) Я же не спрашивал про недостатки своей системы локализации и видите ли Вы проблему в 50 кб? Локализация такая как есть: если бы я сейчас начинал проект с нуля, я бы конечно же делал иначе. Но человек предполагает, а господь бог располагает. Если бы у ПО не было недостатков — незачем бы было выпускать новые версии. К сожалению, по молодости я локализацию не продумал. А теперь поздно... (ну или весьма трудоемко)
А>>>У меня одна из программ переведена на 31 язык, вот бы был гемор, если все эти языки были отдельными дистрибутивами с отдельными URL... C>>Для кого гемор то? Вот приходит пользователь, выбирает версию с нужным языком и скачивает? Он что все версии подряд будет скачивать? Зачем? Или Вы сами? Или закачать проблема?
А>Мне кажется или вы действительно не понимаете, что у меня всего ОДИН дистрибутив?
Почему не понимаю? Я прекрасно Вас понял, и поверьте я знаю достоинства такого подхода — есть у меня еще 2 софтины где именно так и сделано. Но в данном случае НЕ так! И деваться сейчас уже некуда. А>И в нём все языки перевода. Зачем скачивать всё подряд? Зачем вообще выбирать — пользователи этого боятся. Должна быть одна большая ссылка "Скачать", всё. Иначе теряете пользователей. Я о домашних, правда.
Дык у меня и есть ссылка одна + к ней TITLE "другие локализованные версии см. в этом разделе" А>Возможно, у вас софт корпоративный (раз уж с MS себя сравниваете Противопоставляю
А>>>У меня переводы хранятся в ini-файлах — никаких проблем с переводом у добровольцев, C>>Аналогично. Но не для этого случая. Иконки Вы тоже будете хранить в ини-файлах?
А>Если бы вопрос о локализации стоял сейчас, а не несколько лет назад, то я бы для хранения языковых данных использовал бы XML файлы. Проблем с хранением иконок не вижу там.
Что-то совсем мы в сторону ушли... Я же не предлагал обсуждать систему локализации?
А>>>к тому же есть бесплатные утилиты типа Ini Translator, которые еще больше процесс облегчают. C>>К тому же написать самому такую же бесплатную утилиту, и проще, и быстрее и заточить ее под свои нужды тем напильником каким нужно... Уж это то как процесс облегачает.
А>Нда, похоже месье знает толк в извращениях
Причем тут извращения? Все мы ошибаемся, изначально я локализацию вообще не продумывал — молод был, потом было поздно и нужно было найти решение, которое
1) Решит. проблему локализации. Позволит переводчикам переводить только текст не видя структуры UI. Иначе они ее таки ломают. Да и вообще, когда переводчик видит только текст — он и переводит уж куда лучше, когда всякие мутные инструкции, ему абсолютно непонятные, не отвлекают от его работы.
2) Сделать ее таким образом, чтобы все таки прошивалась локализации в проект более или менее статически, чтобы я мог прогнать в Debug конкретную локализованную версию, и посмотреть на нее, на проблемы. А не заставлять пользователя ловить глюки с каждым новым переводом.
3) Решить проблему локализации так, чтобы не надо было переписывать 80% проекта буквально через строку. Иначе эта локализация во столько сил, времени и денег обойдется что еще и стоит подумать о ее необходимости. Т.е. решение должно быть сравнительно недорогим хотя бы в смысле сил и времени.
Я эти проблемы решил. Все работает и вполне успешно. А Вы мне предлагаете на 200 процентов другую локализацию, хотя я о ней не спрашивал? Через строку поминаете меня рядом с MS, хотя постами выше я специально расписал противопоставление?
Ну и кто тут извращенец то после этого?
А>Меня почти все ваши высказывания удивляют Напоминает разговор с линуксоидами — они примерно так же реагируют.
А меня Ваши удивляют! Я задал конкретный вопрос, ответа не получил. Зато получил массу советов, и без единого примера... А>Ну как может быть проще и быстрее писать свой Ini Translator, если он уже есть, бесплатный и в исходниках?
Ссылку приведите, пожалуйста.
C>>В общем, читаем старт топик. Если бы был возможен, ну или хоть бы приемлем выход локализации через ини, я бы так и сделал. Благо опыт есть и далеко не единственный. Но в моем случае это непримлемо по целому ряду причин, да и то если на них "забить" все равно возникнут определенные проблемы, к примеру те же "иконки" или ресурсы прошитые в код.
А>Ну... тут уж вам выбирать — или один раз разрешить геморрой, переделав саму систему локализации (благо языков перевода у вас пока мало), либо на протяжении жизненного цикла проекта решать вопросы о том, как же стимулировать скачивания локализованных версий
1) Ну давайте обсудим новую систему локализации, в конце концов я не мало поломал голову когда столкнулся — мне просто интересно довести решение до лучшего уровня, возможно совершенно по другой схеме.
2) Ваш 31 язык... На чем Ваша программа написана?
3) Задачи "локализации" и "стимулировать скачать" — близкие и родственные, одна от другой пляшет. Но это не одно и тоже. Можно решить второе, не переделвыя с нуля первое. Тут 33 вопроса еще по п. "локализация" — мы все можем ее написать, но будет ли она работать и решать проблемы описанные выше? Раз 100% уверенности нет, приходится подумать о смежных решениях, а не бросать все и писать с нуля новую локализацию (за нее никто не платит).
А>ну и постараюсь ответить по существу вопроса. Исходя из факта, что локализацию менять не будем. И исходя из получения максимума посетителей с поисковиков.
Ну наконец то! Суббота что ли, ей богу? Как Толстые пишем уже по 2-3 страницы на пост, и только потом к существу (я и себя тоже ввиду имею ).
А>Для каждого языка перевода выделяем на сайте свой поддомен (не отдельную папку!) и там для каждого языка положить хотя бы по одной страничке, с правильным заголовком и оптимизированным под правильные ключевые слова заданного языка. Ну и ссылка на скачивание локализованной версии.
Т.е. все таки основательный SEO? Хм... и именно домен даст такой ошеломительный результат? Сейчас есть только отдельные страницы. А>Очень бы полезно было сделать для каждой локализации свой PAD, в котором ссылки на локализованные страницы (поддомены) сайта.
Так и есть (для основных языков): отдельные ПАДы, с отдельными ссылками на конкретный дистрибутив, описание... А>Продукт при этом надо конечно же по-разному называть. Идеальный вариант — продукт называть хорошей ключевой фразой на нужном языке. Это был бы очень серьезный подход к локализации, я уверен он бы работал с хорошей отдачей, но сил и средств потребует тоже — огого. Можно просто к названию продукта добавлять название языка. Например My Product Italian.
Хм... Интересная мысль, и на сайте тоже? У меня в немецком нечто подобное было MyProduct German А>Главное чтобы имена отличались. Просабмитить робософтов, что даст внешние ссылки, а следовательно и кое-какую видимость в выдаче гугла. Дальше уже проводить оптимизацию для каждого поддомена отдельно. А>При заходе на главный домен, можно в зависимости от языка браузера редиректить на нужный локализованный поддомен.
Уж больно смело редиректить — MS затрахал на своем сайте редиректить на русский... Ну сам я решу куда мне надо. Но все равно решение.
PS: вопросы (лбами бодаться это святое — но действительно интересно, т.к. мое решение рабочее, но далеко не идеальное. Хочется довести идею до ума)
1) А что у Вас за проект (31 язык, текстовая локализация)
2) На чем он писался?
Здравствуйте, Begemot_, Вы писали:
B_>Здравствуйте, Carc, Вы писали:
C>>Ну разве что так... Но все равно многие скачивают с файлопомоек по прямой ссылке, хотя и в этом случае можно извратиться. B_>Пряма ссылка элементарно редиректится на скрипт, который уже может определять страну...
B_>еще варианты. B_> 1. веб инсталлер, например как у гугл хрома
Стремно, прога не для сети. Хотя тоже вариант. Минусы: если он сразу из инсталлера не пойдет, а и по разным причинам: некогда, хочет быстро посмотреть, хочет проверить именно эту версию, то потом он уже не вернется к инсталлеру. А это имхо важный момент: если юзер все таки пользуется, то собственно ему по идее то локализованная версия и нужна. А к инсталлеру он не возвращается, ибо поставил и пользуется. B_> 2. нормальный инсталер, но при запуске проверяется язык системы и если есть локализованная под этот язык, говорим об этом пользователю (на его языке) и настойчиво советуем пойти скачать, разумеется с возможностью поставить инг.
Суть имхо та же что и в п.1. Может проще на первой странице инсталлера показывать прямые ссылки на локализованные версии? Минусы те же: + народ привык к инсталлерам, многие просто быстро кликают на Next, не особо разглядывая. B_> 3. пункт меню в проге — обновится до локализованной версии (с автоматической скачкой\установкой)
Не мастер я в этом, к сожалению. Боюсь нормальный use case, usability такого решения я сделаю дай бог раза с 30-го (к тому моменту все забьют на эту возможность окончательно). Может быть действительно просто сделать меню "Язык" в программе и оттуда прямые ссылки на локализованные версии. Плюсы: зато URL откроется в браузере и в целом все подконтрольно пользователю: он знает что и куда он скачал, куда поставил!?!
К примеру, если сделать меню "Язык" на верхнем уровне, пункт в главном меню — то не заметить его будет сложно — внимание привлечь вроде должно получиться. Минусы: кто ожидает от меню "Язык" похода за скачкой? Неожиданное поведение. Правда, тут я как раз могу выйти из проблемы — у меня к каждому пункту меню рядом "ползает" подсказка чего делает меню, причем написана она по человечески, с советами, рекомендациями, и действительно со смысловой нагрузкой. В такой подсказке можно писать что начнется скачка локализованной версии по прямой ссылке!?!
Может так?
Вот оно, блин, проклятие выбора
Спасибо за рекомендации.
С вашего позволения пропущу обсуждение локализации, вашу позицию понял. Ваш проект — вам виднее
Кратко отвечу на вопросы, которые были в той части.
Мой проект, где 31 язык перевода написан на Delphi, в качестве "локализатора" используется доработанный напильником модуль: http://www.koders.com/delphi/fid95A0451E6745CBC0A798C09C28B31F5925A96484.aspx?s=xml
Это как пример, для новых проектов я бы не стал (да и не использую) этот вариант, просто отвечаю на ваши вопросы.
А>>Для каждого языка перевода выделяем на сайте свой поддомен (не отдельную папку!) и там для каждого языка положить хотя бы по одной страничке, с правильным заголовком и оптимизированным под правильные ключевые слова заданного языка. Ну и ссылка на скачивание локализованной версии. C>Т.е. все таки основательный SEO? Хм... и именно домен даст такой ошеломительный результат? Сейчас есть только отдельные страницы.
Не только домен, но и оптимизация страниц под те ключевые фразы, по которым софт ищут аборигены, то есть не на английском.
Я не такой уж и спец по SEO, но моё мнение — разные домены гугл воспринимает как разные сайты — это удобнее в плане оптимизации.
Если по какой-то причине он решит забанить, то забанится поддомен, а не весь сайт.
А>>Очень бы полезно было сделать для каждой локализации свой PAD, в котором ссылки на локализованные страницы (поддомены) сайта. C>Так и есть (для основных языков): отдельные ПАДы, с отдельными ссылками на конкретный дистрибутив, описание...
нынче PADы нужны только для SEO, а главное в SEO — внешние линки. Так что в PAD-ах для разных продуктов еще и ссылки должны стоять на разные локализованные страницы. Так эффективнее.
А>>Продукт при этом надо конечно же по-разному называть. Идеальный вариант — продукт называть хорошей ключевой фразой на нужном языке. Это был бы очень серьезный подход к локализации, я уверен он бы работал с хорошей отдачей, но сил и средств потребует тоже — огого. Можно просто к названию продукта добавлять название языка. Например My Product Italian. C>Хм... Интересная мысль, и на сайте тоже? У меня в немецком нечто подобное было MyProduct German
Если называть продукт ключевой фразой на нужном языке — конечно на сайте тоже. А если нет — то просто чтобы файлопомойки не забанили автоматически за сабмит одинакового продукта с разными ссылками несколько раз. То есть достаточно только в PAD-е.
Вам надо понять две вещи:
1. Вы пытаетесь переложить СВОИ проблемы на пользователей.
2. Пользователи НИКОГДА не станут решать Ваши проблемы, тем более за деньги.
Отсюда вывод — Вы пытаетесь решить не ту проблему, лучше переделайте как можно скорее.
У меня программа переведена на 40 языков или около того, как бы Вы разгребали все это?
Здравствуйте, Allix, Вы писали:
A>Здравствуйте, Carc, Вы писали:
A>Вам надо понять две вещи: A>1. Вы пытаетесь переложить СВОИ проблемы на пользователей.
Не утверждал бы так радикально. Я просто хотел им предложить выбор и только, и сделать его более очевидным для в первую очередь заинтересованных пользователей: т.е. которые скачали и им понравилось. Все остальные меня интересует в меньшей степени, это все равно не картошкой торговать — причины отказа будут далеко не из-за локализации...
A>2. Пользователи НИКОГДА не станут решать Ваши проблемы, тем более за деньги.
Такое обобщение уже тоже долетает до небывалых высот абстракции ((С) Сполски). А если бы было две версии Pro + Lite нужно было бы обе впихнуть в архив? Чтобы у пользователей не было проблем, и все было бы под рукой?
Я не предлагаю обсуждать кто на кого перекладывает проблемы — если покупают значит их устраивает именно такое распределение проблем и их решений. A>Отсюда вывод — Вы пытаетесь решить не ту проблему, лучше переделайте как можно скорее.
Я полагаю это мы уже обсуждаем не ту проблему. Я задал четкий вопрос Как сделать для пользователя возможность выбрать язык версии более очевидной, с учетом того что это дефакто разные файлы?
Меня же начинают убеждать в том, что нужно все локализовать иначе.
Во первых это не ответ на мой вопрос:
1) Это не предоставление пользователю выбора. Я не собирался собрать все до кучи, я хотел предоставить выбор.
2) Если есть немецкий пользователь который купил версию (и его тем не менее видимо все устраивает), то работа по впариванию всех остальных языков в одну версию абсолютно для него бессмысленна. Это ему не нужно. Пока я буду заниматься этой работой, все остальное будет стоять на месте.
A>У меня программа переведена на 40 языков или около того, как бы Вы разгребали все это?
Да легко бы разгреб бы. Я Вам сейчас запросто приведу примеры Вашего решения, что разгребать по своему алгоритму будете до 2012 года. Повторюсь: у каждого свои реалии, поэтому и решения разные. Но думаю опыт можно почерпнуть из многих и понять и плюсы и минусы каждого. А "поделить всё и всё тут" это не решение.
— объем перевода?
— объем программы?
— критичен ли выпуск не полностью переведенной версии?
— если выходит новая версия, а часть нового UI не переведена на 38 языков, что делаете? Задерживаете версию, выпускаете с кривым переводом, удаляете перевод?
И.т.д. без деталей — это не разговор.
Господа товарищи коллеги убедительно прошу давайте что-то решим: или мы говорим о 40 переводах в одном дистрибутиве и тогда нужно обсуждать как они делаются, работают, обновляются, какая политика: пусть не полный перевод, неполный сразу удаляется из новой версии или как, и в таком же духе. Иначе это конь сферический в вакууме. Я как минимум уже применял 4 (четыре) схемы локализации. И все они на 110 (сто десять, а не сто) процентов зависели от сути проекта, объема, частоты выхода версий. Без таких нюансов решить про конкретную локализацию что она лучше, нельзя! Лучше для чего, для каких нюансов?
или обсуждаем вопрос, который я задал
Как сделать выбор на скачку локализованной версии более очевидным? В инсталлере? На сайте? Ссылки из приложения, из меню, показывать диалог с выбором? Хотя бы по той простой причине, что подобная работа это все-таки не 3 месяца, а пара дней. И тут можно пренебречь вероятностью выбора неверных решений (пишем, пробуем, решаем = меняем или оставляем).
.
Вам же надо на странице закачки делать большую кнопку на скачку наиболее подходящего файла (определять по языку ОС, IP, и т.п.) и ниже все остальные варианты.
У меня 6 дистрибутивов и мне кажется это очень много, все время думаю как упростить выбор пользователю. Чтобы я делал с 6*40... повесился бы. А вернее отказался от переводов вобще, кроме 2-3.
Да, и еще тут пришло в голову. Решение с выбором на странице загрузки очевидное, и раз уж Вы его не применяете по каким-либо причинам, то есть еще вариант. Предлагайте скачать локализацию при первом запуске, лучше если скачка и интеграция будет проходить в один клик — без лишних телодвижений со стороны пользователя.
. A>Вам же надо на странице закачки делать большую кнопку на скачку наиболее подходящего файла (определять по языку ОС, IP, и т.п.) и ниже все остальные варианты.
Ну пожалуй так можно, чтобы предполагаемо нужный язык оказывался вверху списка?
Тут такая фича, что у меня приличная доля скачек из тех которые именно с сайта (файлопомойки пока не рассматриваем), идут с входной страницы "с шапки" что называется. Там пара кнопок из серии "Download" да "Buy Now" — и больше туда не стоит впихивать: эти кнопки так хорошо работают, что их мало, разбираться не надо, нажал и понеслось. Если там будет "мануал по выборе версии с 5 кнопками", то это вообще перестанет быть эффективным. Но есссна кнопка ведет на английскую версию? Может туда просто банально впихнуть тот же JavaScript на ссылку на кнопке: который будет спрашивать скачать английскую (по умолчанию) или перейти к выбору локализованных версий?
Вроде с одной стороны все неплохо, но с другой стороны лишний MessageBox? Отчасти конечно можно оптимизировать: что этот яваскрипт с вопросом будет генериться на лету и только для тех пользователей, у которых выставлен нужный язык и тот который есть в версиях!?!
A>У меня 6 дистрибутивов и мне кажется это очень много, все время думаю как упростить выбор пользователю. Чтобы я делал с 6*40... повесился бы. А вернее отказался от переводов вобще, кроме 2-3.
Ну много переводов это то же не гут. У меня фактически так и есть: развиваются 3 иногда 4 перевода, 5-ый редко, 6-ой вообще застрял. Но имхо так и нужно: вон Рошал с ВинРаром сделал — есть скачка аглицкой версии, а рядом есть ссылка на список версий "Latest Localized Versions" — и там видно, что Евгений не старается поддерживать все локализованные версии прям столь одновременно и интенсивно, отдельные локализованные версии по сравнению с текущей вышли достаточно давно.
У меня кнопка, когда была, вела на страницу закачки, ибо 6 (ну или 3 в лучшем случае) инсталятора никак не объединить. Можете сделать нечто вроде выпадающего списка по нажатию на кнопку — 3-4 самых вероятных языков и "еще...".
Рошал может хоть на голове стоять — "мы не они, они не мы"
Здравствуйте, Allix, Вы писали:
A>Здравствуйте, Carc, Вы писали:
A>Да, и еще тут пришло в голову. Решение с выбором на странице загрузки очевидное, и раз уж Вы его не применяете по каким-либо причинам, то есть еще вариант. Предлагайте скачать локализацию при первом запуске, лучше если скачка и интеграция будет проходить в один клик — без лишних телодвижений со стороны пользователя.
Вполне возможно, только я в размышлениях как это предложение при запуске сделать!?!
MessageBox? Да не очень-то он хорош... Пользователь поработать захотел, познакомиться — а тут начинается "а ни жылаите, а ни изволите". И понеслось: "Да, да! Жилаю! Хачу! Запускайся сфолочь". Примерно как с советами дня при старте — шняга полная: юзер стартует программу — ему что-то надо, у него конкретная цель. А ему не дают перейти к выполнению его собственной задачи, да к тому же советы дают вообще из другой степи, никак не связанной с его сиюсекундной задачей.
Если честно, многие смотрят советы дня при старте софта? Я обычно отключаю через 2-3 запуска, да и то потому что ученый опытом: там действительно может быть что-то немаловажное.
Вот коли бы такие советы показывать немодально тогда бы работало.
Имхо: что-то подобное нужно делать и с предложением покачать локализованные версии! Это должно быть немодально. Т.е. надо оно тебе, есть время читать советы мастеров (еще бы! мы все из страны советов — это мы умеем ), тогда клик по ссылке и пошел смотреть. Некогда? Просто ингорируешь такое предложение.
Такие вещи можно, например, сделать в StartScreen`е (выбор действия пользователя: "создать документ, открыть последний, перекомпилить последний" — я об этом). Но у меня такого СтартСкрина с выбором нет, и не нафиг он явно никому не нужен.
Как вариант я развлекался с гиперссылкой на MDI-маме. Если все документы закрыты — человек узрит гиперссылку. Но в том то и дело, что у меня как правило что нибудь да открыто. И ссылка на мди-маме просто не видна.
В общем, в этом то вся и загвоздка: показать выбор можно и имхо лучше в приложении ибо я там царь и бог. Но показать надо так чтобы
а) видно было, чтобы пользователь воспринял эту информацию — иначе игра не стоит свеч.
б) но показать так, чтобы не мешать ему при ознакомлении. Никаких MessageBox`ов с вариантами "А ни жылаите версию на языке Гете?" Ибо не желает он, он хочет познакомиться с программой, посмотреть вообще что да как. Мешать ему нельзя. Если юзер занят другой целью, он один хрен никуда не пойдет, да и раздражать это его будет.
Здравствуйте, Allix, Вы писали:
A>Здравствуйте, Carc, Вы писали:
A>У меня кнопка, когда была, вела на страницу закачки, ибо 6 (ну или 3 в лучшем случае) инсталятора никак не объединить.
На сайте? Или в смысле в софтине? A>Можете сделать нечто вроде выпадающего списка по нажатию на кнопку — 3-4 самых вероятных языков и "еще...".
Меню на Яваскрипте? A>Рошал может хоть на голове стоять — "мы не они, они не мы"
Да не! Я не в смысле "громких имен", в смысле у него видел такой подход, скорее озвучил лишь чтобы пример "именной", с адресом.
Блин, столько слов, так мало дела. Ну детали реализации, столько вариантов сразу в голову приходит. У Вас MDI, сделайте типа тулбарчик такой справа, как в фотошопе — слои там еще какая-то фигня. А в этом тулбарчике предложение с выбором локализации. И не мешает и на виду. Можно просто сообщить о наличии локализации — если программа подойдет, юзер вспомнит что что-то такое про локализацию говорили.
Здравствуйте, Carc, Вы писали:
C>Здравствуйте, Allix, Вы писали:
A>>Здравствуйте, Carc, Вы писали:
A>>У меня кнопка, когда была, вела на страницу закачки, ибо 6 (ну или 3 в лучшем случае) инсталятора никак не объединить. C>На сайте? Или в смысле в софтине?
На сайте конечно, на главной. теперь такой кнопки нет.
A>>Можете сделать нечто вроде выпадающего списка по нажатию на кнопку — 3-4 самых вероятных языков и "еще...". C>Меню на Яваскрипте?
Ну я то откуда знаю как Вам удобнее? У меня все на статичном хтмл, я в этом не бум-бум.
A>>Рошал может хоть на голове стоять — "мы не они, они не мы" C>Да не! Я не в смысле "громких имен", в смысле у него видел такой подход, скорее озвучил лишь чтобы пример "именной", с адресом.
А я и говорю, как делают громкие имена нам может и не подойдет, там некоторые вещи по другому работают, так что равняться надо осторожно.
Здравствуйте, Carc, Вы писали:
C>Как стимулировать скачивание локализованных версий?
Сейчас, по-моему, модно одно из двух. Либо делать универсальные программы, способные выбирать язык в зависимости от текущей локали, либо угадывать национальность пользователя по тому, из какой страны пришел connect (это можно сделать по IP-адресу).
В любом случае должен быть достаточно очевидный способ переключиться на английский, чтобы не расстраивать людей, которые временно оказались не в своей стране или не в своей локали.
A>>>Можете сделать нечто вроде выпадающего списка по нажатию на кнопку — 3-4 самых вероятных языков и "еще...". C>>Меню на Яваскрипте? A>Ну я то откуда знаю как Вам удобнее? У меня все на статичном хтмл, я в этом не бум-бум.
Т.е. просто переход к списку локализованых версий в конкретном разделе, так?
A>>Можете сделать нечто вроде выпадающего списка по нажатию на кнопку — 3-4 самых вероятных языков и "еще...". C>Меню на Яваскрипте?
а если так как на сайте микрософта когда качаешь чтото? ссылка на закачку, а под ней комбобокс с выбором языка, после смены языка меняется урл на скачку (плюс пытается угадать какой мне надо язык и его сразу подставить)
А с другой стороны, гнать какого-нить испанца или немца на аглицкую страницу со списком локализованных версий... Лишний выбор, читать что там на странице написано, лишние клики — имхо тоже не будет способствовать!?!
