|
 | Барби |
 | Компилятором булочек |
|
| |
| Cpt. Blank @ 03 февраля 2012, 04:28 | | 3) Востребована, думаю, программа будет поболее на западе. Поэтому, ИМХО, русский и английский языки должны быть. |
Изначально всё на англ. языке. В Qt присутствуют средства для локализации, так что перевести если что будет не проблема.
| Cpt. Blank @ 03 февраля 2012, 04:28 | | 4) Можно на примере суть диалекта? |
Например, официальная и фанатская локализация на английский могут быть представлены в виде двух диалектов английского. Или зацензуренная версия и версия без цензуры, где в одном варианте будет "госпиталь", а в другом - "церковь" (вспоминая первую финалку), при том весь остальной текст идентичен, за исключением ещё нескольких таких различий. Вот эти различия и определяются диалектом.
| Vitamant @ 03 февраля 2012, 09:13 | Предложение к: Возможность: Многопользовательская поддержка
На первых парах оповещать о том, что документ в данный момент редактируется и блокировать к нему доступ. В дальнейшем - реализовать возможность совместного редактирования. |
Я склоняюсь к системе коммитов - т.е. всё хранится локально, а изменения применяются по запросу пользователя. Это экономит трафик, место на сервере, делает данные в коммитах связанными по смыслу, позволяет проще разрешать конфликты.
Как компромисс, можно сделать два режима - пассивный (коммиты) и активный (изменения передаются на сервер сразу же).
| Vitamant @ 03 февраля 2012, 09:13 | Нарушение принципа универсальности:
Возможность: Визуализация текста
Возможность: Списки свойств
Возможность: Свойства-переменные с определяемой семантикой
Возможность: Импорт и экспорт (в контексте трех предыдущих) |
Списки свойств нисколько не нарушают универсальность. Это как теги в XML - они универсальны, их можно называть как угодно и хранить какие угодно данные, поэтому так много форматов хранятся в XML. Или как переменные в программах, они ведь используются так, как надо программисту.
Визуализация текста - будет по умолчанию базовый модуль с возможностью создать свой конфиг под него (вид окна, шрифт, правила поведения и т.п.), он не мешает универсальности и подойдёт для многих случаев. В особо сложных ситуациях придётся прибегнуть к написанию плагина/модуля/скрипта, вот тут уже универсальность не оспоришь.
Свойства-переменные - даже не знаю, чем могут испортить универсальность. Особенно, если сделать возможность задать их поведение скриптом или модулем/плагином.
А импорт/экспорт, я считаю, к универсальности не относятся, т.к. это просто дополнительные средства "общения" с внешним миром.
| Vitamant @ 03 февраля 2012, 09:13 | Тяжеловестность:
Возможность: Контроль версий + Возможность: Управление разницей версий перевода |
Увы, но контроль версий - одна из основных необходимых возможностей. Хотя, в тех же системах контроля версий исходных кодов вроде нет тяжеловесности, да и для клиентской стороны это всё прозрачно. Так что не думаю, что и здесь возникнут какие-то особые проблемы. А разница версий перевода - это просто дополнительный набор строк вместо дублирования наборов строк целиком.
| Vitamant @ 03 февраля 2012, 09:13 | Конфликты:
Возможность: Управление разницей версий перевода + Возможность: Глоссарий |
Конфликты неизбежны. Но методы их разрешения тоже существуют 
| Vitamant @ 03 февраля 2012, 09:13 | Единственное предложение по схеме:
Context -> Платформа |
Понятие "платформа" ограничивает область применения контекста, потому что им может быть что угодно, хоть региональные различия, хоть различия версий какой-нибудь программы, хоть вероисповедание целевой аудитории.
Спасибо за отзывы, всё приму к сведению |
|
