Multilingual typing: main locale is not guaranteed to be dictionaryGroups[0] (HashSet in getUsedLocales)

クローズ
  • 何か問題がありますか？
#762 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
3/5
見積もり時間
半日
初心者へのやさしさ
62/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
android, kotlin
領域
internationalization, mobile

調査の方向性

Start in DictionaryFacilitatorImpl.getUsedLocales(), where hashSetOf(mainLocale) is built, and in getNewDictGroupsAndDictsToCleanup(), which creates the groups in that set's iteration order. Then check the dictionaryGroups[0] call sites the issue lists: mainLocale, currentlyPreferredDictionaryGroup, getSuggestionResults(), isActive() and LatinIME.resetSuggestMainDict(). Done when the main locale is always group 0 regardless of Locale.hashCode(), for example with a linkedSetOf change, and a test or debug output confirms the order for en_US with de.

索引モデルが issue の本文から書いたものです。

説明

Describe the bug
With a secondary language (multilingual typing), the main locale of the layout is not guaranteed to be the first dictionary group. DictionaryFacilitatorImpl.getUsedLocales() collects the locales in a HashSet:

val locales = hashSetOf(mainLocale)
locales.addAll(getSecondaryLocales(selectedSubtype.extraValue))

getNewDictGroupsAndDictsToCleanup() creates the groups in the iteration order of that set, and a HashSet doesn't keep insertion order. But a lot of code assumes dictionaryGroups[0] is the main locale:

  • mainLocale = dictionaryGroups[0].locale, also used by LatinIME.resetSuggestMainDict(), which calls resetDictionaries(this, dictionaryFacilitator.mainLocale, ...). If that is the secondary locale, getUsedLocales() goes into the "called from the spell checker" branch, and as far as I can see the keyboard can end up with only the secondary language.
  • currentlyPreferredDictionaryGroup = maxBy { it.confidence } returns the first group on a tie. At the start all groups have confidence 1, so the tie goes to whichever locale the HashSet put first.
  • getSuggestionResults() queries only group 0 synchronously and waits at most 120 ms for the others.
  • isActive(), isValidSuggestionWord(), the personal-dictionary check in addToUserHistory() and dumpDictionaryForDebug() also use group 0.

Which pairs are affected depends on Locale.hashCode(). A quick check on a desktop JVM (Java 21) shows the secondary locale first for 7 of 12 common pairs, e.g. main en_US + secondary de, fr or es, and main nl or pl + secondary en_US. On our devices (Android 15/17), de_DE + en_US happened to come out in the right order, so Android's order differs from the JVM, but it is still not defined.

Possible fix
Keep the insertion order (that's what we did):

val locales = linkedSetOf(mainLocale)

To Reproduce

  1. Set up a layout with a secondary language via Multilingual typing, e.g. English (US) with German.
  2. Depending on the pair, the secondary locale becomes dictionaryGroups[0]. With debug mode on, the space bar shows the order of the locales (localesAndConfidences()).

Expected behavior
The layout's main locale is always the first dictionary group.

App version & Flavor
Found in GlassType, my fork, now based on LeanType 4.3.1 (0e673e1). The code is unchanged in current main.

Device Info

  • Model: Samsung Galaxy Z Fold 3 (SM-F926B) and Galaxy S23 Ultra (SM-S918B)
  • OS version: Android 15 / Android 17
主要言語
Kotlin
スター
1k
フォーク
59
平均マージ
14時間 9分
マージ済み PR（30日）
56

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

LeanBitLab/LeanType のほかの issue

LeanBitLab/LeanType の issue をすべて見る

似ている issue

Kotlin の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。