Feat/korean lsp docs

[qtaghdi]

Summary

Adds localized editor documentation support to the OverPy language server, following the approach discussed in review.

This keeps Workshop compilation/decompilation locale data separate from the language used for editor documentation.

What changed

• Changed data description fields to use LocalizableString
• Added src/data/opy/documentation.ts for documentation-specific strings such as:
  • Arguments:
  • Type:
  • Returns:
  • enum / variable / subroutine descriptions
• Added Korean (ko-KR) translations for the documentation UI strings
• Added a separate overpy.documentationLanguage setting
  • defaults to auto
  • auto follows the VS Code / LSP client locale
  • falls back to en-US when a localized string is unavailable
• Updated completion, hover, and signature-help generation to resolve localized strings directly from the data model
• Updated the DataTool localization generator so description GUIDs are used for lookup without being persisted in the source data
• Added localization and fallback tests

Behavior

The documentation language is independent from workshopLanguage, so compiling or testing Workshop code in another language does not change the editor documentation language.

Existing Workshop locale values are preserved; this PR only changes how documentation strings are represented and selected.

Validation

Validated against the current upstream master with:

• pnpm run check-types
• pnpm run lint
• pnpm run test:core
• pnpm run test:cli
• pnpm run test:lsp

The upstream GitHub Actions workflow also passes successfully.

Thanks for the direction on the localization architecture.

[Zezombye]

I had a concept for documentation localization a while ago, but never got to finish it due to lack of demand.

The approach should rather be to change the description field in all data-related types (in the /src/data dir) to a LocalizableString, that is:

    "wait": {
        "guid": "000000007872",
        "description": {
            "en-US": "Pauses the execution of the action list. Unless the wait is interrupted, the remainder of the actions will execute after the pause.",
            "ko-KR": "동작 목록의 실행을 일시 중지합니다.\n대기가 중단되지 않으면 남은 동작은 대기 시간이 지난 뒤 실행됩니다.",
        },
        "args": [...],
        ...,
    }

You can use Datatool to automatically get all the translations of the descriptions (the guid should NOT be stored, as it would otherwise overwrite manual changes to the descriptions, and the descriptions won't change anyway).

Then you can also create data/opy/documentation.ts which would host all the necessary strings for the documentation (such as "Arguments:"), and then modify the lsp to get strings from there.

The choice of documentation language should be an additional setting in the vs code extension, and should be by default based on the vs code language (so that, if someone compiles for another language for testing purposes, they aren't faced with unreadable documentation).

Thanks :)

[qtaghdi]

Thanks, that makes a lot more sense.

I agree that localizing the source documentation data directly is cleaner than post-processing the generated Markdown.

I'll refactor this PR to:

make documentation description fields use LocalizableString
update the DataTool generation logic without persisting description GUIDs
move common documentation strings into data/opy/documentation.ts
add a separate documentationLanguage setting with VS Code's language as the default/fallback

Thanks for the detailed direction :)

[qtaghdi]

Thanks for the feedback, I’ve reworked the implementation based on your suggestions.

The documentation is now localized directly in the data model using LocalizableString, and I added a separate documentationLanguage setting that defaults to the VS Code locale instead of relying on workshopLanguage.

I also updated the DataTool generation logic while preserving the existing Workshop locale data, and added tests for localization and fallback behavior.

All core, CLI, and LSP tests are passing now