Would a selectable menu display language (e.g. Simplified Chinese) be welcome? #2303

Closed
opened 2026-11-11 14:07:53 +00:00 by gx0803 · 4 comments
gx0803 commented 2026-11-11 14:07:53 +00:00 (Migrated from github.com)

The idea

Would a selectable menu display language be welcome?

I'd like to gauge interest before writing a larger change. Hookshot's in-game menu is currently English-only.
The game itself already ships Simplified Chinese (and other) text and CJK fonts, but the options menu drawn by
hookshot_vk.dll has no way to change its own display language. Players who don't read English have to use a
community patch that rewrites the compiled DLL.

Is upstream open to the menu having a selectable display language, at least English + Simplified Chinese,
with more languages addable later? If so, does the approach below look acceptable, or would you prefer a
different direction?

Proposed approach (draw-time translation)

  • English strings stay exactly as they are in the source. They are also the ini keys and the subjects of a few
    strcmp comparisons (ini_key(), is_motion_row(), cheat_value(...) == "On"), so they must not be renamed.
  • A generated, self-contained header holds an en -> zh table; a tr(const char*) looks up the string at the
    draw call only and returns the original pointer in English or when a string is untranslated. No comparisons
    or keys ever see translated text, so saved settings and the cheat-toggle highlights keep working.
  • A Language tab after Debug holds one English / 简体中文 row, applied at once (no restart), saved as
    menu_lang in hookshot_options.ini.
  • For CJK glyphs, the host reads the game's own bundled Chinese .bfttf faces. The romfs .bfotf files
    are never modified — replacing them crashes the guest font loader, so the plan is a .bfotf → .bfttf
    filename fallback in vk_game_font.h plus a font choice in vk_imgui.cpp.

Questions for you

  1. Is a menu language selector something you'd consider merging, or is English-only intentional?
  2. Does draw-time translation (English source strings + a generated table) fit the project, or would you prefer
    gettext-style catalogs / a different structure?
  3. Any concern about reading the game's own .bfttf faces for the menu font, versus shipping a separate font?
  4. If this is welcome, should the first PR be a minimal English + Simplified Chinese slice, with the Inventory
    and Teleport pages follow-ups?

I have a working, compiling prototype on a v2.1.0 fork (56 draw sites, a generated 430-entry table, one small
test). Happy to open it as a PR, rebase on main, and split it however is easiest to review. No game data or
generated files would be included.

This is a screenshot of part of the game menu after the localization is completed

e089bc0cc8d01c580fabb165250020b0 25a404211eb059cde316b496f21e05b4 f49e2225d508bf47e83ff8b609a7dc95 c19cdd848aa68b87d332e9c4205b58a3

Assisted-by: WorkBuddy (Claude) — drafting and code research.

Anything else

No response

### The idea ## Would a selectable menu display language be welcome? I'd like to gauge interest before writing a larger change. Hookshot's in-game menu is currently English-only. The game itself already ships Simplified Chinese (and other) text and CJK fonts, but the options menu drawn by `hookshot_vk.dll` has no way to change its own display language. Players who don't read English have to use a community patch that rewrites the compiled DLL. **Is upstream open to the menu having a selectable display language**, at least English + Simplified Chinese, with more languages addable later? If so, does the approach below look acceptable, or would you prefer a different direction? ### Proposed approach (draw-time translation) - English strings stay exactly as they are in the source. They are also the ini keys and the subjects of a few `strcmp` comparisons (`ini_key()`, `is_motion_row()`, `cheat_value(...) == "On"`), so they must not be renamed. - A generated, self-contained header holds an `en -> zh` table; a `tr(const char*)` looks up the string at the **draw call only** and returns the original pointer in English or when a string is untranslated. No comparisons or keys ever see translated text, so saved settings and the cheat-toggle highlights keep working. - A `Language` tab after Debug holds one `English / 简体中文` row, applied at once (no restart), saved as `menu_lang` in `hookshot_options.ini`. - For CJK glyphs, the host reads the **game's own** bundled Chinese `.bfttf` faces. The `romfs` `.bfotf` files are never modified — replacing them crashes the guest font loader, so the plan is a `.bfotf` → `.bfttf` filename fallback in `vk_game_font.h` plus a font choice in `vk_imgui.cpp`. ### Questions for you 1. Is a menu language selector something you'd consider merging, or is English-only intentional? 2. Does draw-time translation (English source strings + a generated table) fit the project, or would you prefer gettext-style catalogs / a different structure? 3. Any concern about reading the game's own `.bfttf` faces for the menu font, versus shipping a separate font? 4. If this is welcome, should the first PR be a minimal English + Simplified Chinese slice, with the Inventory and Teleport pages follow-ups? I have a working, compiling prototype on a `v2.1.0` fork (56 draw sites, a generated 430-entry table, one small test). Happy to open it as a PR, rebase on `main`, and split it however is easiest to review. No game data or generated files would be included. This is a screenshot of part of the game menu after the localization is completed <img width="2559" height="1431" alt="e089bc0cc8d01c580fabb165250020b0" src="https://github.com/user-attachments/assets/9c5cc6b2-c16d-47ee-bea2-9e6862f6f8da" /> <img width="2595" height="1425" alt="25a404211eb059cde316b496f21e05b4" src="https://github.com/user-attachments/assets/03afd60c-1292-4d62-a52a-1565afbac055" /> <img width="2613" height="1440" alt="f49e2225d508bf47e83ff8b609a7dc95" src="https://github.com/user-attachments/assets/51c35b05-b43c-4a29-86ce-032daaa953c9" /> <img width="2730" height="1434" alt="c19cdd848aa68b87d332e9c4205b58a3" src="https://github.com/user-attachments/assets/901ca1ab-476c-4141-ad4f-90ac7ae7896c" /> Assisted-by: WorkBuddy (Claude) — drafting and code research. ### Anything else _No response_
l326108519-lab commented 2026-11-11 14:52:50 +00:00 (Migrated from github.com)

支持支持 虽然我自己拿ai汉化了

支持支持 虽然我自己拿ai汉化了
gx0803 commented 2026-11-11 15:23:32 +00:00 (Migrated from github.com)

支持支持 虽然我自己拿ai汉化了

嗯嗯,我反正自己fork了,以后有版本更新也可以一边同步最新版本,一边保持中文支持😄

> 支持支持 虽然我自己拿ai汉化了 嗯嗯,我反正自己fork了,以后有版本更新也可以一边同步最新版本,一边保持中文支持😄
NotRexed commented 2026-11-11 21:28:37 +00:00 (Migrated from github.com)

Thanks for the report. Reports of the same problem are now collected in #1007, which lists this one with your details and links back here, so one fix closes them together and the open list stays readable. Follow #1007 for the fix, and add new details there (or here). If this turns out to be a separate problem it will be reopened.

Thanks for the report. Reports of the same problem are now collected in #1007, which lists this one with your details and links back here, so one fix closes them together and the open list stays readable. Follow #1007 for the fix, and add new details there (or here). If this turns out to be a separate problem it will be reopened.
gx0803 commented 2026-11-12 02:46:05 +00:00 (Migrated from github.com)

@NotRexed OK,Thank you very much~~

@NotRexed OK,Thank you very much~~
Commenting is not possible because the repository is archived.
No milestone
No assignees
1 participant
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
MagicBeanDev/Hookshot#2303
No description provided.