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

未關閉
  • 哪裡不對？
#762 0 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 1 天內回覆

還沒有人認領這個 Issue。

評估

難度
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 分鐘
30 天內合併 PR
56

環境準備

從這裡開始

  1. 先讀完整個 Issue，再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫，在一個分支上完成修改。
  4. 送出 Pull Request，並在描述裡引用這個 Issue 編號。

LeanBitLab/LeanType 的其他 Issue

查看 LeanBitLab/LeanType 的全部 Issue

相似的 Issue

更多 Kotlin Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。