Есть такой проект dxgettext для локализации приложений. В делфи я его широко использую, есть его версия и под java. Для перевода есть редактор poEdit. Думаю его намного удобнее использовать чем родной андроидный локализатор.

Наверное никогда не пользовались dxgettext? Смысл этого проекта в том что он может выбрать все строковые ресурсы для перевода в отдельный файл, этот файл передается человеку-переводчику, который с помощью poEdit в удобном виде переводит текст (т.е. они видит табличку с 2-мя колонками, слева н-р руские фразы, а справа на том языке, который он переводит), есть там и подгрузка новых данных без потери переведенных, потом из этого редактора выгружается другой файл, который и подключается в программу с помощью своей поддержки, которая автоматически заменяет в памяти программы строковый ресурс (поиск по фразе) на соответствующий перевод.
А в андроиде - пробовал в эклипсе - так там что нужно передать переводчику - сами файлы со строковыми ресурсами и у него поедет крыша или же он чего так отредактирует что нарушит структуру. Или я не прав?

wadmanМикола ПитерскийИли я не прав?
dxgettext не видел, но встроенные средства так или иначе равны. Когда-то я писал клон jimm-а и для него была разработана утилита, в которой на мой взгляд наиболее удобно сделана возможность создавать переводы. В ней выбирался оригинал (англ), и дополнялся переводом. Т.е. было три столбца: название переменной (используется в коде), английская версия и перевод. Если dxgettext нечто подобное, то можно глянуть.

Остальное, на мой взгляд, не стоит внимания. Особенно выдирающее сообщения из исходных кодов, т.к. там много служебной информации, которая не может быть переведена, таких как log.*, интенты и акции.

Сам редактор переводов смотрите в приложенной картинке.

Что выдирать из исходных кодов легко настраивется в файле-включить и в файле исключить. Вот для делфи из файла ggexclude.cfg :
[exclude-form-class]
TWebBrowser
TdxStatusBar
TrsPropSaver

; FastReport
TfrxReport
TfrxBarCodeView
TfrxGroupHeader
TfrxMasterData
TfrxDBDataSet
TfrxPictureView
TfrxMemoView
TfrxReportPage

[exclude-file]
report.dfm
Wizard.dfm

[exclude-dir]

Плюс dxgettext в том что он выбирает для перевода только уникальные фразы - т.е. если у вас много кнопок с тектом "нажать сюда" - то к переводчику попадет только ОДНА эта фраза. А то что вы надеетесь самостоятельно при помощи онлайн переводчика перевести программу на 20 языков - это все туфта - нужен профессиональный переводчик, а они используют только poEdit.

wadmanМикола ПитерскийСам редактор переводов смотрите в приложенной картинке.
GNU Gettext for Delphi and C++ Builder к яве не имеет отношения.
Микола Питерскийнужен профессиональный переводчик, а они используют только poEdit
Боюсь, что это оффтоп в теме про яву и андроид в частности, т.к. это отклонение от стандарта локализации . У указанного ПО слишком узкое направление и до андроида оно не дотягивает, чуть меньше, чем полностью.
Не учитывает ни размера экрана, ни его положения, ни способа управления и т.д.

Так ты смотри Gettext for Java - в сети есть пример использования его под Java. В делфи есть свой встроенный локализатор еще со времен делфи7 - так что кое-кто тоже может сказать - что это "отклонение от стандартов". И не понял - причем здесь размер экрана и т.д. (русский текст всегда длиннее иностранного)?
Декомпилируй Навител навигатор для АНДРОИДА и увидишь что они используют именно .mo файлы для локализации из этой программы poEdit, а не андроидную стандартную локализацию.

wadman,

Вот нагуглил: http://www.alek.ws/blog/2014/Apr/08/gnu-gettext-in-java.html

Добавлю что есть gettext и для PHP - так что это очень удобный проект - просто его надо попробовать и поработать в нем и все "Стандартные" локализации после него идут лесом. poEdit - это не просто редактор - это программа-переводчик - т.е. вы один раз переводите фразу и она сохраняется в базе и потом автоматом переводится такая же фраза, ну там много таких класных фишек и это надо пробовать. Файлик .mo - это скомпиленый для одного языка перевод и он затем обрабатывается средством поддержки в соответствующем языке, т.е. могут автоматически заменяться фразы, найденные в этом файле или же принудительно через функцию _("Привет мой свет!").

wadmanХинт: в андроиде встроенный механизм автовыбора необходимых ресурсов. Условия их выбора можно подсмотреть по ссылке или на картинке ниже. Грубо говоря подключаемый языковой ресурс может зависеть от всех перечисленных условий. Например с ландшафте подхватится полный текст, а в портрете - сокращенный и т.д.


Ну так это и хорошо - у тебя есть стандартный файл локализации ТОЛЬКО для русского языка для портрета и ланшафта. Н-р "Выводит список" и "Вывод списка с подробной информацией". При повороте экрана грузится сотвествующий ресурс, затем срабатывает поддержка gnugettext и переводит эти соотвесттвующие фразы.

wadmanМикола ПитерскийПри повороте экрана
Чтобы прикрутить левую фичу мне придется писать больше кода:
1. Загрузка текстов, что в свою очередь меня лишает использования методов, где указывается идентификатор строки.
2. Обработка смены конфигурации, где еще и определять при каких условиях какой файл подгружать. С этим прекрасно сам андроид справляется, лучше чем большинство начинающих программистов для андроида.

1. Никто не запрещает по прежнему использовать идентификатор строки
2. Обрабатывать ничего не надо - андроид сам это сделает - тут вмешательство минимально - в событии старта активности вызываем метод gnutext который определит язык в системе и он сам будет знать какой файлик (класс жавы) подгрузить, затем когда все ресурсы загрузятся вызывам другую функцию, которая и выполнит перевод всех строковых ресурсов, эту же функцию вызываем н-р в событии поворота устр-ва.
Можете использовать попрежнему строковые ресурсы, а можно и без них _('Привет'). Так что вмешаетельства в ваш код тут вообще минимальны. Если кто смог с эклипса перелезть на студию - то легко сможет освоить и эту систему.

Микола ПитерскийПри повороте экрана грузится сотвествующий ресурс, затем срабатывает поддержка gnugettext и переводит эти соотвесттвующие фразы.

Если кто не понял - при повороте экрана все происходит как и раньше - андроид грузит ваш родной строковый ресурс локализации, который по умолчанию, т.е. добавлять как раньше для других языков эти ресурсы уже не надо - т.к. перевод будет делать gnutext по своим файлам *.mo, которые преобразуются в соответсвующий класс java.

wadmanМикола ПитерскийЕсли кто не понял
Я не понял, можно пример кода с минимальным вмешательством, где выбирается файл хотя-бы по ориентации экрана? А то смахивает на общение слепого с глухим.

Во это точно - я тоже хотел так написать :) Ничего из gnutext дополнительно не выбирается см. предыдущее мое сообщение, все остается как и было - андроид сам подгружает нужный ресурс и лишь потом gnutext просматривает все "значения строк" и изменяет если найдет в своем .mo файле строки на соответсвующие переводу. А все остается как и было раньше.

wadman, если подробно - то откомпилированные файлы *.mo , полученные из программы переводчика средствами утилит gnugettex переводятся в жава классы, н-р было 20 файлов языков, получилось 20 жава классов (я все это дело проверил - классы формирует нормально), вы эти классы подключаете к проекту, подключаете gnugettex и вызываете его функцию, которая определит какой жава клас вызывать (в зависимости от языка системы).
В любых событиях, которые подгружают новые ресурсы вы после загрузки этих ресурсов вызываете функцию, которая перебирает все строковые ресурсы и заменяет их из из соответствующего класса-перевода. Вроде все.

wadmanМикола Питерскийандроид сам подгружает нужный ресурс и лишь потом gnutext просматривает все
Это ничего не пояснило.

Вот примеры вызовов:


Андроид сам подгрузил строку из нужного ресурса, я указал только константу. Как оно переведет мне это?

Конкретно для этого случая:

Микола Питерскийwadmanпропущено...

Это ничего не пояснило.

Вот примеры вызовов:


Андроид сам подгрузил строку из нужного ресурса, я указал только константу. Как оно переведет мне это?

Конкретно для этого случая:




ошибся - вот так:

wadman

И строки тут будут выбираться средой в зависимости от условий (см. выше) из разных строковых ресурсов.

gnugettext не осилит такое на автомате.

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





а затем уже срабатываеет функция gnugettext, которая и выполнит перевод:

wadmanМикола ПитерскийКонкретно для этого случая:
Еще один вопросик: опыт применения имеется или это теоретическое применение (в этом примере)? :)
Это точно работает?

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

chpashaМикола, я выражу свой вопрос кодом



делаем функцию, которая переберет все классы TextView и переведет их строковые ресурсы, естественно это при выводе на экран, далее повторяем эту функцию во всех событиях, связанных с повторным чтением ресурсов.

wadmanchpashaи все это ради возможности иметь отдельный файл для переводчика?
Есть такой инструмент: Google translate toolkit, если разобраться, то толковая штука, в т.ч. позволяет отправлять файлы ресурсов профессионалам или делиться с друзьями для совместного перевода.

Гугл думает о своих. :)

Да - только там:
• Android Resource (.xml)
• Application Resource Bundle (.arb)
• Chrome Extension (.json)
• GNU gettext-based (.po)

Вот последняя строка это и есть .po файл, который генерирует gettext для редактора poEdit. И в гугле знают что это классная вещь:)

chpashaМикола ПитерскийВот последняя строка это и есть .po файл, который генерирует gettext для редактора poEdit. И в гугле знают что это классная вещь:)но почему-то к андроиду ее не прикрутили
К делфи и пхп тоже ее не прикрутили. Насчет того что медленно будет выводится приложение при повороте экрана из-за перевода - врядли - одно дело изменять объекты в памяти - а другое производить дисковое чтение из анроидных ресурсов и также перерисовывать контролы с новым текстом. Меня не столько напрягает невозможность иметь отдельный файл для перевода, как вероятность многократного дублирования текста в контролах приложения н-р "Название, закрыть и т.д" их может быть много одинаковых в контролах с разными идентификаторами и они разбросаны по файлу ресурсов и при переводе надо проделывать лишнюю работу, также вы отдали на перевод файл с ресурсом и вдруг решили переименовать идентификатор этой строки - все основной файл переведенным уже нельзя заменить, аналогично вы добавили новый контрол в этом случае тоже нельзя файлы менять, а надо ручками найти изменения и их добавить. Всех этих недостатков нет в gnugettext.
А может я и не прав - т.к. есть пока в андроиде небольшой опыт и только в эклипсе.

Вот мне не нравится эклипс по причине - если я пишу одноязычное приложение и пытаюсь текст контрола написать прямо в исходнике - то он этот текст подчеркивает (как в настройках отключить эту проверку для всего приложения я не нашел) и предлагает поместить его в файл ресурсов и соответственно мне надо придумать название идентификатора этого текста в ресурсе - т.е. много лишней работы, которую я не люблю делать. И кроме того почему ему (эклипсу) не пройтись по всем строковым ресурсам и не сказать что уже есть такой ресурс с текстом "название:" и не предложить в исходнике присвоить контролу этот идентификатор?
Может в студии это сделано лучше? Год назад смотрел студию - там у меня она висла при создании проекта - т.е. я ее так и не увидел в действии.