Форум Flasher.ru
Ближайшие курсы в Школе RealTime
Список интенсивных курсов: [см.]  
  
Специальные предложения: [см.]  
  
 
Блоги Правила Справка Пользователи Календарь Поиск рулит! Сообщения за день Все разделы прочитаны
 

Вернуться   Форум Flasher.ru > Flash > ActionScript 3.0

Версия для печати  Отправить по электронной почте    « Предыдущая тема | Следующая тема »  
Опции темы Опции просмотра
 
Создать новую тему Ответ
Старый 27.09.2017, 01:22
Appleman вне форума Посмотреть профиль Отправить личное сообщение для Appleman Найти все сообщения от Appleman
  № 1  
Ответить с цитированием
Appleman
 
Аватар для Appleman

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
По умолчанию Заложить основу мультиязычности

Вопрос к опытным коллегам (хотя какой я вам пока коллега ).

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

На концептуальном уровне всё вроде бы понятно. Будущая многоязычность моего приложения основывается на следующих принципах:
1. Никаких жёстко заданных текстов внутри кода. Только идентификаторы, по которым будут подбираться текста на выбранном пользователем языке;
2. Все тексты живут в неких "накопителях". У меня пока это "классы-хранители" со статическими методами и переменными типа Object, хранящими тексты по строковым идентификаторам. В дальнейшем буду думать, что с ними делать: менять на XML или ещё что-нибудь, пока это представляется несущественным;
3. Между игровой механикой и готовыми текстами, живущими в классах-хранителях, должна быть ещё отдельная языковая логика. Например, для русского языка требуется подбирать слова в нужных падежах, а в английском - нет. Таким образом, просто выдёргивать по одним и тем же идентификаторам строковые переменные из идентичных хэшей точно не получится. Значит между игровой механикой и "складом" строковых переменных должны быть ещё некие "посредники", осуществляющие эту самую языковую логику.

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

Стал прикидывать, как сделать... Это может быть один класс для всех языков, но запускающий разные методы, в зависимости от выбранного языка. Или базовый класс и классы-наследники для каждого из поддерживаемых языков, переопределяющие методы. Может быть вообще пространства имён или ещё какая-нибудь экзотика. Пока ограничился тем, что отделил игровую механику от подбора текстов, плюс создал пакет language, куда скинул эти самые классы-хранители и классы-"подбиратели" текстов.

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

Старый 27.09.2017, 02:34
undefined вне форума Посмотреть профиль Отправить личное сообщение для undefined Найти все сообщения от undefined
  № 2  
Ответить с цитированием
undefined

Регистрация: Oct 2006
Сообщений: 2,281
Мне кажется ,ты сам себе проблему придумываешь в 99% случаев форма слов известна заранее и не меняется. Максимум для числительных две формы задавать надо:lives_single/lives_plural. Но оно и для англ. локали требуется.
Только если ты не делаешь супер рпг, которая должна будет генерить диалоги на лету.


Последний раз редактировалось undefined; 27.09.2017 в 02:49.
Старый 27.09.2017, 07:24
caseyryan вне форума Посмотреть профиль Отправить личное сообщение для caseyryan Найти все сообщения от caseyryan
  № 3  
Ответить с цитированием
caseyryan
 
Аватар для caseyryan

Регистрация: Jun 2012
Адрес: Новосибирск
Сообщений: 6,644
Записей в блоге: 4
Цитата:
Наверняка есть общая практика и отработанные решения
конечно есть, гугли по запросу i18n
Но в общем, ты выбрал правильный подход. Только на формы слов действительно имеет смысл забить. Для игры это значения не имеет, как у же сказал undefined
__________________
Ко мне можно и нужно обращаться на ты)

Старый 27.09.2017, 15:55
Appleman вне форума Посмотреть профиль Отправить личное сообщение для Appleman Найти все сообщения от Appleman
  № 4  
Ответить с цитированием
Appleman
 
Аватар для Appleman

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
Цитата:
Сообщение от undefined Посмотреть сообщение
Мне кажется ,ты сам себе проблему придумываешь в 99% случаев форма слов известна заранее и не меняется. Только если ты не делаешь супер рпг, которая должна будет генерить диалоги на лету.
Супер-не супер, но до фига текста собирается из кусков по ситуации, где, например, фигурируют собственные имена персонажей, которые должны подставляться из переменных. Как тут без падежей обойтись для русского языка?

Цитата:
конечно есть, гугли по запросу i18n
О! Спасибо. Кто бы мог подумать, что это такой хренью обзовут! Сам бы не догадался.

Старый 27.09.2017, 19:44
caseyryan вне форума Посмотреть профиль Отправить личное сообщение для caseyryan Найти все сообщения от caseyryan
  № 5  
Ответить с цитированием
caseyryan
 
Аватар для caseyryan

Регистрация: Jun 2012
Адрес: Новосибирск
Сообщений: 6,644
Записей в блоге: 4
это просто сокращение от internationalization. i и n первая и последняя буквы, а 18 - количество букв между ними. Есть еще l10n - localization
__________________
Ко мне можно и нужно обращаться на ты)

Старый 29.09.2017, 00:52
Nooob вне форума Посмотреть профиль Отправить личное сообщение для Nooob Найти все сообщения от Nooob
  № 6  
Ответить с цитированием
Nooob
 
Аватар для Nooob

Регистрация: Mar 2007
Сообщений: 319
используй по возможности текста со всеми комбинациями, если есть огромные комбинаций (невозможно обработать вручную) используй выражения в которых постановочные слова используют в именительном падеже
вместо: Изготовьте %item%, чтобы выполнить задание
так: Изготовьте предмет %item%, чтобы выполнить задание
практика показывает что квадратичные комбинации не составляют проблем для описания каждой, зато выражение более лаконичны
__________________
RocketJump


Последний раз редактировалось Nooob; 29.09.2017 в 01:03.
Старый 29.09.2017, 10:20
Appleman вне форума Посмотреть профиль Отправить личное сообщение для Appleman Найти все сообщения от Appleman
  № 7  
Ответить с цитированием
Appleman
 
Аватар для Appleman

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
Цитата:
практика показывает что квадратичные комбинации не составляют проблем для описания каждой, зато выражение более лаконичны
Чего-то я с квадратичными комбинациями не понял, о чём речь. Можешь пояснить последнюю фразу, пожалуйста?

Старый 04.10.2017, 10:52
Appleman вне форума Посмотреть профиль Отправить личное сообщение для Appleman Найти все сообщения от Appleman
  № 8  
Ответить с цитированием
Appleman
 
Аватар для Appleman

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
Друзья, хочу обновить тему. Почитал я то, что нашёл на родном языке по i18n, спасибо за наводку, но в подавляющем большинстве статей описываются лишь общие подходы. Удалось почерпнуть оттуда, что, например, помимо непосредственно языка не следует забывать о форматах дат и времени, валюте и т.п. Это всё прекрасно и понятно.

Из своих собственных изысканий пока пришёл к тому, что как и планировал изначально, полностью отделил игровую механику от текстов и вообще языка, создал классы-хранители с ассоциативными массивами, забитыми текстом, а между ними добавил классы-посредники с языковой логикой. Причём все обращения к классам-хранителям строятся с помощью методов с идентичной сигнатурой: Id-шник на входе, переменная типа String на выходе - ничего лишнего.

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

2. Всё равно остаётся много вопросов не по общей организации (что нужно интернационализировать), а по практической реализации мультиязычности в приложении. Кто делал, поделитесь опытом плиз или кусок кода приведите, если не секрет. Мучаюсь выбором, то ли оставлять единые классы с языковой логикой, но внутри их писать отдельные методы для каждого языка, то ли отдельные классы делать... То же самое и с хранением инфо о выбранном языке: просто в виде идентификатора в каком-нибудь классе типа Config, или в виде пространства имён, чтобы потом писать методы с одинаковыми названиями, но вызывать с помощью пространства имён нужную версию. В общем, просьба помочь советом.

3. Есть понимание, что как уже было замечено многими коллегами здесь на форуме, хранить тексты в коде - не дело. Действительно, не дело. Думаю переходить к XML, чтобы и дополнительные языки подключались. А вот как это практически сделать, не понимаю? От слова совсем. Вопрос загрузки и чтения данных из файла XML не стоит - это много где описано с примерами. А вот как создавать сам файл и набивать туда данные? Руками это не делается. Значит, нужно писать отдельную программу или дополнительные классы в своей программе, которая будет из моих статических таблиц с идентификаторами "забивать" строковые значения в XML. Так? А если потом ещё какие-то текста добавить нужно... Совсем нет понимания технологии такой работы.

Старый 04.10.2017, 21:12
Wolsh вне форума Посмотреть профиль Отправить личное сообщение для Wolsh Найти все сообщения от Wolsh
  № 9  
Ответить с цитированием
Wolsh
Нуб нубам
 
Аватар для Wolsh

модератор форума
Регистрация: Jan 2006
Адрес: Бердск, НСО
Сообщений: 6,445
1>>Интерфейсы могут быть реализованы только экземплярами. Другими словами, статические методы интерфейсами не регламентируются.

2>>Пространства имен не дадут тебе возможности добавлять языки, не переписывая код. Ведь для нового языка тебе придется добавить пространство имен и соответствующие методы. Надо абстрагировать систему так, чтобы программе было совершенно фиолетово, какой язык.
Ты вот приводил пример, что в английском нет падежей. Ну так это значит, что все замены будут однотипные в именительном падеже. То есть везде в тексте будет $n0, и не будет $n1...$n5. А в массиве замен будет просто одно имя John, а не Маша в шести падежах. И поэтому один и тот же алгоритм сможет обрабатывать текст и на русском и на английском. Почему? Потому что разница только в данных, и если данные Текст соответствуют данным Замены, то никаких проблем не будет. Такой же степени абстракции кода надо добиться во всех других случаях. Например, формат даты и времени тоже можно как-то единообразно зашифровать и передавать в файле языковых данных, например там <dataFormat>DD.MM.YYYY</dataFormat>. И написать парсер (мне кажется это не так уж сложно) который будет в рантайме форматировать дату-время под заданный формат. То есть постоянный код, не заменяемый с языком, способный отформатировать дату по заданному шаблону (а вариантов форматов, мягко говоря, совсем немного).

3>>Не совсем понял, что значит "руками это не делается"? При чем тут "статические таблицы"? А их кто писал? Не руками? Как-то вообще непонятно, что ты имеешь ввиду.
Я не делал текстовых квестов. Возможность смены языков я делал для приложения типа хранилища и редактора записок, то есть там смена языка только в интерфейсе. Для каждой фразы имеется идентификационный номер. В коде, когда надо вывести текст, идет обращение к классу Language и вызывается его статический метод getText(id:uint):String. Этот класс в начале программы загружает XML, в котором все фразы хранятся со своими идентификаторами, например в Eng.xml так:
<phrase id="123684">The File $&fileName is broken.</phrase>
а в Rus.xml так:
<phrase id="123684">Файл $&fileName поврежден.</phrase>

Как программа узнает, какой файл языка загрузить и применять? Его название хранит config.xml, который программа загружает самым первым и из него берет пути к остальным настроечным файлам — теме оформления интерфейса, истории открывавшихся файлов, файлу языка.

То есть, по-порядку:
программа загружает config.xml
в нем указано <language>Rus</language>
программа активирует класс Language, передавая ему путь загрузки "Rus.xml"
Language открывает этот файл и считывает его в объект XML
программа двигается дальше, отрисовывает интерфейс, периодически обращаясь к Language.getText(#) —
ей не надо ничего знать о том, какой там на дворе язык: Language даст ей фразу на нужном языке и дату/время в нужном формате (шаблон русского формата указан в Rus.xml)
__________________
Reality.getBounds(this);

Старый 05.10.2017, 10:25
Appleman вне форума Посмотреть профиль Отправить личное сообщение для Appleman Найти все сообщения от Appleman
  № 10  
Ответить с цитированием
Appleman
 
Аватар для Appleman

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
Цитата:
Сообщение от Wolsh Посмотреть сообщение
1>>Интерфейсы могут быть реализованы только экземплярами. Другими словами, статические методы интерфейсами не регламентируются.
Спасибо, понятно. Вопрос пока снят.


Цитата:
Надо абстрагировать систему так, чтобы программе было совершенно фиолетово, какой язык. Ты вот приводил пример, что в английском нет падежей. Ну так это значит, что все замены будут однотипные в именительном падеже. То есть везде в тексте будет $n0, и не будет $n1...$n5. А в массиве замен будет просто одно имя John, а не Маша в шести падежах. И поэтому один и тот же алгоритм сможет обрабатывать текст и на русском и на английском.
Угу, логично. Действительно, я смогу добиться единого алгоритма для разных языков. Вот теперь всё в голове более-менее выстроилось в единую картинку. Спасибо, thanks и merci

Цитата:
3>>Не совсем понял, что значит "руками это не делается"? При чем тут "статические таблицы"? А их кто писал? Не руками? Как-то вообще непонятно, что ты имеешь ввиду.
Я имел в виду не само содержание, т.е. фразы, а именно разметку файла XML: все эти теги разных уровней, открывающие, закрывающие и т.п. Поэтому я и спрашиваю, какие есть инструменты для формирования файлов XML для будущего использования.

Цитата:
Как программа узнает, какой файл языка загрузить и применять? Его название хранит config.xml, который программа загружает самым первым и из него берет пути к остальным настроечным файлам — теме оформления интерфейса, истории открывавшихся файлов, файлу языка.
С папками для языков, содержащих файлы xml с идентичными названиями, всё ясно. А сам файл config.xml будет храниться где-то вместе с готовым приложением. Есть какие-либо правила по его размещению? Пока ведь у меня в проекте только то, что сам Flash создал: папка src с классами, bin и ещё чего-то. И загружаем мы этот конфиг прямо на старте программы, скорее всего, создав для этого отдельный класс со статическими методами? А если пользователь что-то меняет в конфиге, то изменяем записи в этом самом config.xml. верно?

Создать новую тему Ответ Часовой пояс GMT +4, время: 17:58.
Быстрый переход
  « Предыдущая тема | Следующая тема »  
Опции темы
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.


 


Часовой пояс GMT +4, время: 17:58.


Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2024, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.