навеяно новостью про FUEL

если бы я не был таким полным расп.*ем каким я есть, я бы это давно реализовал. ибо идея есть, и даже какой-то парсер po на пистоне напейсал.

http://translations.launchpad.net

> http://translations.launchpad.net

фуета, там нету анонимусов

Сделай поиск по моему нику в той теме, я тоже это предлагал. Времени нет.

Посмотрел, интересно, но засилье GTK/Gnome/Ubuntu, сейчас смотрю чего есть на l10n.kde.org

Имхо, надо копать в сторону ковыряния тулкитов.

Повторюсь: "А если уж заговорили про UI, то: посмотрим на среды мелкомягких (вроде бы даже в ворде есть - не могу проверить), где можно в режиме "настройка" не только перевести все меню, расставить хоткеи, но и полностью поменять расположение элементов, иконок, создать свои панели инструментов, вытащить одни кнопки из глубин меню на панели, другие вообще спрятать... А что мешает взять QT-дизайнер, да прямо в *.ui устроить всякие изменения? Не знаю правда как с этим у гномосеков... Остается прикрутить систему версионирования и быстрого редактирование - вот и получилась wiki для ui."

Или сделать хак для Qt/gtk, который бы реализовывал "режим редактирования".

Да, такая контекстная система перевода должна быть удобной - сразу видно, что это за пункт меню, и как его переводить. Наверно реальнее всего это действительно для Qt сделать. Подкиньте идею тролльтехам кто-нибудь =)

собственно идея локализации в wiki + bugtracker + VCS здравая. Тот же Drupal умеет "мультиязычный интерфейс", переводить все сообщения на сайте для двуязычных страничек. Там есть модуль редактор .po файлов, что самое интересное, переводы может ковырять любой посетитель сайта-регистрат. Осталось его прикрутить к wiki ( которые в Drupal 4 были довольно убоги, интересно как, сейчас допилили? хотя в друпале "книги" -- это примерно те же вики).

Интересно, есть модули к вики или Trac для редактора *.po через gettext или Qt-шных *.ts (вроде чистый XML)?

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

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

> Подкиньте идею тролльтехам кто-нибудь =)

Имхо, им нафиг это не нужно. А вот сделать либу-хак - это можно и своими руками сотворить (перехватываем вызовы, обрабатываем, запускаем оригинальные функции). Правда у меня на это нет времени.

гугление нанесло ссылок: http://wiki.civicrm.org/confluence/display/CRMDOC/Internationalisation+guide http://en.wikipedia.org/wiki/Pootle http://wiki.impresscms.org/index.php?title=Translating_Xigg_module (похоже на искомое) тулзы http://en.wikipedia.org/wiki/Translate_Toolkit http://translate.sourceforge.net/wiki/toolkit/ts2po http://trac.vidalia-project.net/browser/vidalia/tags/vidalia-0.1.6/src/tools

интересный обзор по разным SDK http://www.cmake.org/Wiki/KWWidgets/i18n

> надо копать в сторону ковыряния тулкитов.

не понял идею. Есть в Qt родной QtLinguist. GUI редактор *.ts файлов с переводами. Есть конвертор ts2po/po2ts, для конвертирования в GNU-сный *.po. Какие ещё "wiki для ui" нужны? Любой желающий может взять исходный *.ts для Qt или *.po для gettext файл, поправить, протестировать перевод, отослать автору нужного проекта, и ждать пока он его положит в VCS и grammar Nazis заметят ошибки в переводе, которые надо исправить. Что ещё надо?

или идея в том, чтобы у QtLinguist была "глобальная" между разными проектами Translation memory? а он нечётко искал оригинальный текст в своей памяти и предлагал варианты полуавтоматически?

> А так красота - зашел, и исправил в вики.

в любом случае, нужно обсуждение "сомнительных" переводов, желательно, носителями. То ли на ланчпаде то ли на другом ресурсе для переводчиков видел кнопку для голосования "хорошести" перевода, нечётко 0..100%, любой праздношатающийся мог проголосовать и предложить свой вариант (за который тоже можно было проголосовать). Сомнительные переводы утверждались большинством голосов.

> Что ещё надо?

Редактирование "на живую".

Вы заметили ошибку, или кривой перевод - ваши действия? Пойдете разгребать ts2po/po2ts (о которых не все знают), или просто переключитесь на другую локаль? Я сделаю последнее.

А вот в случае "на живую" мне не лень сделать 2 клика и ввести правильный перевод (с моей точки зрения), причем увидеть его сразу, без перезапуска приложения. Это гораздо проще, чем возится с файлами, чего-то пересобирать.

> Сомнительные переводы утверждались большинством голосов.

Сделать разные профили для перевода. Пусть download в одном профиле будет как "загрузить", а в другом "слить". Любители олбанскава сделают себе профиль сами.

вот для Trac есть например плугин для макро в вики http://trac.edgewall.org/wiki/MacroBazaar#WikiFile -- включить версионированный файл. Немного допилить, чтобы можно было при сохранении вики странички запускалось плагином вики макро "выцепить из неё *.po и положить в конкретную версию VCS", и ИМХО, почти всё, что нужно.

> Вы заметили ошибку, или кривой перевод - ваши действия? Пойдете разгребать ts2po/po2ts

поскольку я сам программист, и собираю интересующие меня проекты, если вижу кривой/отсутствующий перевод в интересном проекте, правлю файл с переводом и таки да, пересобираю. Правда, лежит это всё в hg/git в локальной ветке, в апстрим обычно не аплоадю.

Согласен, что если переводы будет сделать проще, их захочется делать любому.

> А вот в случае "на живую" мне не лень сделать 2 клика и ввести правильный перевод (с моей точки зрения),

"два клика" -- где ? на форме? на кнопке? на серой радиокнопке? на секретной кнопке "чтобы ВСЁ перевелось само"?

> причем увидеть его сразу, без перезапуска приложения.

http://www.scribd.com/doc/2173/blanchette-book -- пишут, что *.qm переводы можно обновлять в runtime, QTranslator::load(..) http://doc.trolltech.com/3.3/qtranslator.html#load-2. Правда, вопрос в том, проверяет ли конкретное приложение, что .qm файл переводов изменился и надо загрузить новый, или там жёстко прописана загрузка за 1 раз при старте приложения (+переключении языка в приложении).

Вот в том-то и беда, что телодвижений очень много. Нужно как минимум настроенную систему иметь, где установлен QtLinguist/KBabel, выковыривать файл перевода из системы, а потом еще и разрабу его слать. То есть, если кто-то хочет постоянно переводами заниматься - то да, это не проблема. А если наскоками, как я, то смысла нет все эти приблуды держать.

Я вот где-то в начале года переводил Gwyddion, порядка 700 фраз перевел, а потом забросил, и разработчику забыл отослать - все, пропала работа, неактуально уже. А так другие подхватят.

Я википедию очень уважаю, за то что можно с любого компа (хоть с оффтопиком из универа) в свободное время зайти и править статьи - это очень удобно.

> Сделать разные профили для перевода. Пусть download в одном профиле будет как "загрузить", а в другом "слить".

Как "сливать профили"? вся эта фигня с Translation memory и рассчитана, что есть иерархический стек переводов слова-идиомы-предложения целиком из идиом и слов, где каждый следующий использует предыдущий уровень. Плюс разные куски должны быть согласованы, звучать правильно на целевом языке.

А так по отдельным словам была какая-то прожка под винду, "переводила" ресурсы приложений, сама, по словарю, в автоматическом режиме.. тупо автоматизировано увидел такое словосочетание -- заменил в ресурсах на вот такое

>Вот в том-то и беда, что телодвижений очень много.

> порядка 700 фраз перевел, а потом забросил, и разработчику забыл отослать - все, пропала работа,

ИМХО, это должно решаться на уровне общей вики проекта. В вики лежит оригинальный текст и переводы на его основе, при сохранении редактирования в вики из неё *автоматически* выдирается очередной *.po / *.ts перевод и ложится в SVN/git/что там. То есть, ветку с исходниками в VCS обновляют разработчики, файлы с переводами обновляет асинхронно движок сайта.

И к этому обязательно прикрутить обсуждение/голосовалку "качества перевода", желательно самими аборигенами целевого языка.

Дело за малым -- написать модуль к тому же Trac. Вроде как работать должно -- понятно.

> А так по отдельным словам была какая-то прожка под винду, "переводила" ресурсы приложений, сама, по словарю, в автоматическом режиме.. тупо автоматизировано увидел такое словосочетание -- заменил в ресурсах на вот такое

Нее, это то костыль убогий. Вот товарисч правильно предложил контекстный редактор перевода - пускаем программу, допустим с ключиком --debug-translation, и около каждой надписи в программе появляется у нас пимпочка, за которую дергаем, открывается окошко, где написан исходный текст (на английском) и перевод. Если перевод неправильный - исправляем, или пишем с нуля, жмем ОК, смотрим, как оно в программе выглядит сразу же (не слишком ли длинная надпись) и закрываем программу.

Чудо-машина предлагает:

а) сохранить файл перевода (для текущего пользователя в ~/.foo /translation_override

б) для всех пользователей в /usr/share/locale/ru/foo (нужны права суперпользователя)

в) отослать разработчику (целиком или diff - на усмотрение разраба)

Перевод неоднозначных терминов _существенно_ упростится - чесслово, половина времени уходит на понимание того, а где собственно эта фраза используется, по нескольку раз приходится перевод править иногда.

Есть ещё такой вариант финтом ушами. google: "google scraper" выдаёт ссылку например http://scroogle.org/cgi-bin/scraper.htm , есть другие поисковики вроде Koders.org, и т.п.

Делаем сайт, который через этот сервис ищет новые проекты с *.ts/*.po переводами. Распарсивает страничку, узнаёт, как вытащить из SVN/git/whatever проекта эти файлы, ложит в свою локальную VCS. А сам сайт - сервис для переводов, с вики, голосовалкой, своей веткой.

Авторы проектов, в свою очередь, регулярно сами синхронизируются с VCS этого сайта и вытаскивают оттуда новый перевод.

> в апстрим обычно не аплоадю.

Вот, забыл основную проблему. И самую важную.

> два клика" -- где ? на форме? на кнопке? на серой радиокнопке? на секретной кнопке "чтобы ВСЁ перевелось само"?

И кнопке, и радиокнопке. Я уже приводил в пример движек мелкомягких. Правый клик по форме - настройка. Теперь правый клик по любому элементу, в том числе и "серому" - можем править. ВСЕ. Но (имхо, поправите) тут нужна поддержка со стороны самого приложения, делать пересбор не каждый захочет. Поэтому (опять имхо), тут надо как-то перехватить вызов функций, что-то вроде перехвата сигнала "кликед" по той же кнопке. Просто кликаем - приложение работает как задумано автором. Кликаем, удерживая хоткей - вылетает менюшка с предложением ввести перевод.

> QTranslator::load(..)

А вот как быть с button->setText("Click on me!")?

> --debug-translation, и около каждой надписи в программе появляется у нас пимпочка, за которую дергаем, открывается окошко, где написан исходный текст (на английском) и перевод.

умеет ли приложение грузить переводы *.qm (или что там для gettext) на лету? грузить формы на лету? сделаны формы через переводы или захардкожено? для сферического приложения в вакууме всё неоднозначно..

нужно уметь сказать приложению "загрузи новый файл переводов". Например, переключить локаль туда-сюда.

по-моему, мы не ту часть оптимизируем. Переводы и так вполне удобно поправить через QtLinguist и пересобрать/подгрузить новый. Хотя идея хорошая, ога.

> в) отослать разработчику (целиком или diff - на усмотрение разраба)

по-моему, оптимизировать надо вот это. То есть, править переводы всякими анонимусами сразу в вики проекта, ложить в VCS через сайт. Откатывать если чо.

Вроде несложно должно быть реализовать в конкретном Qt-приложении - к каждому элементу с tr() цепляем дополнительно кнопочку, или вообще по правой мышке/хоткею пункт в контекстное меню, видимый только в --debug-translation mode. При запуске приложения распаковываем .qm в /tmp, или берем из devel-пакета .ts файл, и при вызове соотв. функции ищем в этом .ts файле перевод, и кажем его во всплывающем окошке. При закрыти соответственно выполняем lrelease. Реализуемо?

> А вот как быть с button->setText("Click on me!")?

заменить на button->setText(tr("Click on me!") :)) вынести "Click on me!" в отдельный файл переводов, при инициализации в нужном месте (+переключении локали в приложении) подгрузить перевод. Стандартно всё :)

см. http://www.cmake.org/Wiki/KWWidgets/i18n#Qt

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

если мы про Qt, там достаточно динамично всё, можно перегружать формы и переводы на лету. Если само приложение эту динамичность учитывает, а не тупо грузит 1 раз в самом начале приложения.

Свою библиотечку можно написать, но её кто-то должен использовать, отнаследоваться.

Хотя наверно можно извратиться через LD_PRELOAD грузить какую-то заглушку, которая будет перекрывать стандартные библиотеки Qt.

> Как "сливать профили"?

Профили - независимы друг от друга. Как ветки в svn. Причем очередной профиль может быть основан как на уже готорой локализации (например, русской или китайской), так и на основе оригинала. Смешивать их НЕ нужно, пусть пользователь сам выбирает, чего ему ближе: загрузить или слить. А то таких порой переводов начитаешься, что потом вообще непонятно, где и чего было, хотя внешне все переведено правильно. Профиль - это просто механизм форка перевода, причем с переключателем.

> вся эта фигня с Translation memory и рассчитана, что есть иерархический стек переводов слова-идиомы-предложения целиком из идиом и слов, где каждый следующий использует предыдущий уровень.

В любом случае 100% автоматической генерации не получить, нужна будет контекстная доводка, в рамках конкретного приложения. Нужен перевод для приложения foo - выбирается какой-то язык, если есть - ближайший профиль (что автору больше по душе), на его основе строится _что-то_, которое потом в любом случае допиливается. И если для каждого диалога (фразы, идиомы) будет выбор из нескольких вариантов - это вообще хорошо.

http://www.ibiblio.org/onebase/onebaselinux.com/Ab "нет такой страницы, подумал штирлиц", будет как раз пример того, как я это вижу. Те самые профиля. т.е.

Russian Stranitsa, kotoruyu vy ishete, byla peremeschena na drugoy sait.

Russian Нет такой страницы подумал Штирлиц.

Оба варианта заслуживают права на жизнь.

> сохранить файл перевода (для текущего пользователя в ~/.foo /translation_override

Зачем? Перевод сохраняется всегда. В виде пар "оригинальное значение - улучшенное". А захочет пользователь - и в глобальную директорию сохранит (для всех), и автору отошлет.

Если я правильно понимаю, то button->setText(tr("Click on me!"));

но по сути тоже сказать ничего не могу =)

Боюсь я, "профили перевода" анархию и неразбериху породят

> заменить на button->setText(tr("Click on me!") :)) вынести "Click on me!" в отдельный файл переводов, при инициализации в нужном месте (+переключении локали в приложении) подгрузить перевод. Стандартно всё :)

Сложно :), про tr я в курсе, а вот профессиональная переводчица? Ее тоже заставите исходники править?

> умеет ли приложение грузить переводы *.qm (или что там для gettext) на лету? грузить формы на лету? сделаны формы через переводы или захардкожено? для сферического приложения в вакууме всё неоднозначно..

А низкоуровневый вызов setText самим отловить нельзя?

> Хотя наверно можно извратиться через LD_PRELOAD

Я так и предлагал

> к каждому элементу с tr() цепляем дополнительно кнопочку, или вообще по правой мышке/хоткею пункт в контекстное меню

по хоткею+мышеклику контекстное меню с полем ввода, чтобы прям туда ввести?

>При запуске приложения распаковываем .qm в /tmp, или берем из devel-пакета .ts файл, и при вызове соотв. функции ищем в этом .ts файле перевод, и кажем его во всплывающем окошке. При закрыти соответственно выполняем lrelease.

1. сопоставить виджет строчке в tr(..)
2. подменить файл .qm или что там отредактированным "на лету"
3. заставить перезагрузить наш подменённый файл при редактировании "на лету"
4. при выходе или редактировании окончательно сохранить.

2. думается можно запустить приложение как-то из-под своей программы/библиотеки вроде strace my.app или LD_PRELOAD=mystub_libQt.so my.app.
Чтобы подменить файл временным.

3. -- заставить перегрузить обновлённый файл переводов -- тут неясно. Вроде все должны перегружать при переключении языка в приложении. Но могли и грузить один раз при запуске, придётся перезапускать.

или (и чтобы 1) -- перекрыть "стандартные" setText своей реализацией, которая учитывает эту версию "редактированных на лету".

например, сделать хитрую версию setText ( tr(MSG)) которая поддерживает хеш вида MSG=>id виджета (хендл окна или что там).

После изменения "на лету" либо перезагружается файл переводов целиком/переинициализируется виджет, либо наша реализация посылает виджету "обновись, перерисуйся" (и в фоне обновляет файл переводов)

> А то таких порой переводов начитаешься, что потом вообще непонятно, где и чего было, хотя внешне все переведено правильно.

вот tr(..) в Qt по умолчанию если не находит перевод, возвращает оригинал. Получается слитый перевод/оригинал.

> В любом случае 100% автоматической генерации не получить, нужна будет контекстная доводка,

согласен, но что-то можно полуавтоматизировать. См. в википедии на эту тему. Да и на ЛОРе вот недавно проскакивала ссылка про "нечёткий поиск", оно конечно ерунду порой выдаёт, но ход его мыслей мне нравится :))

> которая поддерживает хеш вида MSG=>id виджета (хендл окна или что там).

Кстати да, полезная штука. Позволит 1 слово (фразу) в разных местах переводить по разному. Только потом надо будет автору слать указания, дабы разные ID повесил на эти разные части.

> "нечёткий поиск", оно конечно ерунду порой выдаёт, но ход его мыслей мне нравится :))

Нет, только не это. Видел я эту игрушку.

А еще я видел 3d studio max 5, где слово "snow" (снег) доблесные переводчики перевели как show (показ). Поди не могли понять, причем тут снег, посчитали опечаткой. Разница - 1 буква. В результате генератор снежинок стал "показом" (непонятно чего)

> а вот профессиональная переводчица? Ее тоже заставите исходники править?

профессиональная переводчица будет править исходник. Файла переводов :))

того же .ts/.po. Этот файл .ts/.po будет генерироваться автоматически из исходников, тулзой, которая выносит tr(blabla) в .po

> А низкоуровневый вызов setText самим отловить нельзя?

на C++? вот в Смоллтоке, Objective C -- точно можно. Там есть такая штука как "Posing As" -- поскольку полиморфизм динамически, методы можно добавить/удалить на лету (см. категории в ObjC), можно перекрыть реализацию базового класса потомком (и все унаследовавшиеся от базового автоматом унаследуются от этого потомка). Можно сделать Proxy-объект, который "притворяется" объектом другого класса, оборачивает их своей реализацией (что-то вроде QueryInterface в COM). При этом приложение не знает, что вместо объекта у него прокси или позёр.

ЕМНИП, это возможно в объектной модели GObject из GNOME.

В С++ без жуткого хака с VTable или чего-то аналогичного с LD_PRELOAD своей реализации что-то не очень придумывается.

Хотя можно просто тупо делать новый setText после редактирования, вдруг прокатит и не успеет перерисоваться :)

А вообще в эпичном треде про xorg.conf что-то похожее получается :))

> В результате генератор снежинок стал "показом" (непонятно чего)

just show off, генератор выпендривался наверное :)))