Существуют ли какие-либо шаблоны / алгоритмы для работы с локализуемой мнемоникой?

Question

Я работаю над продуктом веб-приложения, который позволяет использовать мнемонику (то есть подчеркивание ниже символа «C», чтобы комбинация клавиш и клавиша C вызывали кнопку «Закрыть»).

• Формы создаются разными разработчиками, и каждый из них может статически устанавливать мнемонику для кнопок.
• Формы могут быть вложенными, поэтому не обязательно знать во время разработки точную мнемонику, которая потребуется для одной страницы.
• Может быть не более одной мнемоники с использованием любого символа на странице, содержащей много форм.
• А вот и кикер, формы должны быть в состоянии локализовать на любой язык, а это означает, что буква «C» для закрытия может даже не появиться в слове ... [вставить язык], используемом для «Закрыть».

Идеальным решением был бы некоторый алгоритм, в котором разработчикам не нужно было вручную указывать мнемонику, вместо этого они были бы разработаны во время выполнения, они были бы локализованы, и они были бы удобными и последовательными (я сказал идеальное решение ;-D).

Итак, мне было интересно, есть ли хорошие стратегии для достижения чего-либо, близкого к идеальному решению?

---

РЕДАКТИРОВАТЬ: Чтобы уточнить,

• Я не говорю о клавиатурных ускорителях, таких как Ctrl + S для сохранения, которые скрыты в меню. Мнемоника используется только для действий, которые представлены на экране, например, под ярлыками кнопок. Не скрытые сочетания клавиш, которые могли бы измениться при локализации (в любом случае их нет, мы запускаем их в веб-браузере, поэтому единственными ускорителями являются те, которые являются частью используемого браузера).
• Проблема с попыткой выбрать мнемонику во время разработки заключается в том, что люди, ответственные за разработку пользовательского интерфейса, не знают о локализации, как это могло бы быть сделано несколько месяцев спустя. Кроме того, проблема использования вложенных и модульных форм означает, что даже без локализации может сохраняться конфликт.

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

Конечно, если бы я искал что-то подобное, это соответствовало бы более общему алгоритму - я просто понятия не имею, какой именно! : -)

Answer 1

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

Одна из проблем заключается в том, что в некоторых языках нет ни одной отображаемой буквы, которая отображается на одной клавише на клавиатуре. Другая проблема на английском языке заключалась в том, что стандарты юзабилити требовали, чтобы мнемонические буквы были совместимы с аналогичными в аналогичных кнопках / меню в других приложениях. Это может быть сложно, если вы динамически выбираете буквы.

Я не знаю, можно ли это назвать «наилучшей практикой», но рассмотрим, что делает Microsoft Internet Explorer на японском языке. Обратите внимание на знакомую мнемонику F, E, V, A и D в меню и на панели инструментов. Я полагаю, что там, где это уместно, применяется то же самое соглашение для кнопок на формах и тому подобное.

_{(источник: sidenet.ddo.jp )}

(Я получил этот скриншот из поиска картинок Google . Если он устарел, вы можете довольно легко найти другие картинки с локализованным IE jp )

Answer 2

Это действительно проблема проектирования, а не алгоритмическая проблема. Оказывается, что большинство приложений не локализуют ускорители клавиатуры, в том числе большинство Microsoft, хотя на некоторых рынках есть некоторые исключения. Не каждое сочетание клавиш является мнемоникой; на самом деле, только некоторые из наиболее распространенных из них.

Я должен отметить, что эти выборы не для локализации ускорителей - довольно недавняя тенденция; до 2000 года или около того все еще было довольно распространенным образом локализовать ярлыки в некоторых продуктах (например, Ctrl-F для «Fett» вместо «жирный» в немецких и шведских продуктах). Но маятник качнулся в противоположном направлении, возможно, из-за MUI и подобных особенностей.

Несколько инструментов локализации помогут вам в этом; Я видел эту особенность как пункт о продукте, который я никогда не использовал под названием Visual Localize. Я не уверен, насколько полезно автоматическое назначение, так как довольно сложно автоматически определить, какой символ является лучшим мнемоническим представлением, без знания предметной области конкретного продукта.

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

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

Answer 3

Проблема, с которой я сталкиваюсь при выполнении этого, заключается в том, что происходит, когда вы развертываете версию, которая имеет новые формы и изменяет Close с alt-c на ctrl-c. Или когда у вас есть два действия на двух разных страницах, но они оба близки, вы должны убедиться, что close - это всегда alt-c. Еще хуже было бы, если бы алгоритм основывался на чем-то недетерминированном и мог изменяться со временем без развертывания.

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