Skip to content

feat: international essence#1527

Merged
MistEO merged 6 commits intov2from
feat/internationalEssence
Mar 23, 2026
Merged

feat: international essence#1527
MistEO merged 6 commits intov2from
feat/internationalEssence

Conversation

@Joe-Bao
Copy link
Copy Markdown
Contributor

@Joe-Bao Joe-Bao commented Mar 22, 2026

Yea, I know someone in other countries also need this feat.
fix #1036
支持了语言选项,让我们不止说中文。

Summary by Sourcery

为 EssenceFilter 引擎与流水线添加多语言支持和增强的 OCR 匹配功能。

新功能:

  • 为 EssenceFilter 匹配和界面消息提供可配置的输入语言支持(CN, TC, EN, JP, KR)。
  • 使用与区域设置相关的字段加载技能池与武器数据,并提供本地化的匹配原因与日志记录。
  • 暴露辅助方法,用于解析 EssenceFilter 数据目录并根据不同语言环境规范化 OCR 输入。

增强:

  • 改进跨语言环境的 OCR 规范化与模糊匹配逻辑,包括对英文分词处理和编辑距离的调优。
  • 新增可选的详细匹配追踪功能,可通过环境变量控制,用于调试。
  • 通过新增 input_language 并简化 JSON 解码来优化选项解析。

测试:

  • 扩展 EssenceFilter 匹配测试,以覆盖英文和多语言的模糊精确匹配以及规范化别名。
Original summary in English

Summary by Sourcery

Add multi-language support and enhanced OCR matching for the EssenceFilter engine and pipeline.

New Features:

  • Support configurable input language (CN, TC, EN, JP, KR) for EssenceFilter matching and UI messages.
  • Load skill pools and weapon data using locale-aware fields with localized match reasons and logging.
  • Expose helpers to resolve the EssenceFilter data directory and normalize OCR input per locale.

Enhancements:

  • Improve OCR normalization and fuzzy matching logic across locales, including English token handling and edit-distance tuning.
  • Add optional detailed match tracing controlled via environment variable for debugging.
  • Refine option resolution by adding input_language and simplifying JSON decoding.

Tests:

  • Extend EssenceFilter match tests to cover English and multi-lingual fuzzy exact matching and normalization aliases.
Original summary in English

Summary by Sourcery

为 EssenceFilter 引擎与流水线添加多语言支持和增强的 OCR 匹配功能。

新功能:

  • 为 EssenceFilter 匹配和界面消息提供可配置的输入语言支持(CN, TC, EN, JP, KR)。
  • 使用与区域设置相关的字段加载技能池与武器数据,并提供本地化的匹配原因与日志记录。
  • 暴露辅助方法,用于解析 EssenceFilter 数据目录并根据不同语言环境规范化 OCR 输入。

增强:

  • 改进跨语言环境的 OCR 规范化与模糊匹配逻辑,包括对英文分词处理和编辑距离的调优。
  • 新增可选的详细匹配追踪功能,可通过环境变量控制,用于调试。
  • 通过新增 input_language 并简化 JSON 解码来优化选项解析。

测试:

  • 扩展 EssenceFilter 匹配测试,以覆盖英文和多语言的模糊精确匹配以及规范化别名。
Original summary in English

Summary by Sourcery

Add multi-language support and enhanced OCR matching for the EssenceFilter engine and pipeline.

New Features:

  • Support configurable input language (CN, TC, EN, JP, KR) for EssenceFilter matching and UI messages.
  • Load skill pools and weapon data using locale-aware fields with localized match reasons and logging.
  • Expose helpers to resolve the EssenceFilter data directory and normalize OCR input per locale.

Enhancements:

  • Improve OCR normalization and fuzzy matching logic across locales, including English token handling and edit-distance tuning.
  • Add optional detailed match tracing controlled via environment variable for debugging.
  • Refine option resolution by adding input_language and simplifying JSON decoding.

Tests:

  • Extend EssenceFilter match tests to cover English and multi-lingual fuzzy exact matching and normalization aliases.

@Joe-Bao Joe-Bao marked this pull request as ready for review March 22, 2026 13:01
Copilot AI review requested due to automatic review settings March 22, 2026 13:01
Copy link
Copy Markdown
Contributor

@sourcery-ai sourcery-ai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey - 我发现了 4 个问题,并留下了一些高层次的反馈:

  • skillCoreCandidate 中,你在搜索分隔符 "·"/"・" 之前调用了 normalizePunctuation,但 normalizePunctuation 已经把这些分隔符替换成空格了,所以基于分隔符的拆分永远不会触发;可以考虑调整调用顺序,或者修改归一化逻辑,在拆分完成之前保留这些分隔符。
  • 新增的按 locale 进行归一化的辅助函数(例如 normalizeStopwordsForLocalenormalizeSimilarIfLocale)会重复调用 NormalizeInputLocale;你可以在每条代码路径中只对 locale 进行一次归一化,然后传递归一化后的值,以避免重复工作并让调用点更清晰。
Prompt for AI Agents
Please address the comments from this code review:

## Overall Comments
-`skillCoreCandidate` 中,你在搜索分隔符 `"·"`/`"・"` 之前调用了 `normalizePunctuation`,但 `normalizePunctuation` 已经把这些分隔符替换成空格了,所以基于分隔符的拆分永远不会触发;可以考虑调整调用顺序,或者修改归一化逻辑,在拆分完成之前保留这些分隔符。
- 新增的按 locale 进行归一化的辅助函数(例如 `normalizeStopwordsForLocale``normalizeSimilarIfLocale`)会重复调用 `NormalizeInputLocale`;你可以在每条代码路径中只对 locale 进行一次归一化,然后传递归一化后的值,以避免重复工作并让调用点更清晰。

## Individual Comments

### Comment 1
<location path="agent/go-service/essencefilter/matchapi/util.go" line_range="148-151" />
<code_context>
 	return utf8.RuneCountInString(s)
 }

+// skillCoreCandidate strips game UI suffix after a separator (e.g. rank/size) for matching.
+func skillCoreCandidate(display string, locale string) string {
+	display = strings.TrimSpace(normalizePunctuation(display))
+	for _, sep := range []string{"·", "・"} {
+		if idx := strings.Index(display, sep); idx >= 0 {
+			return strings.TrimSpace(display[:idx])
</code_context>
<issue_to_address>
**issue (bug_risk):** normalizePunctuation 在 skillCoreCandidate 搜索分隔符之前就移除了它们,导致预期的分割行为失效。

`normalizePunctuation(display)` 会把 `"·"``"・"` 都替换成空格,但之后你又依赖这些分隔符来截掉 UI 后缀:

```go
display = strings.TrimSpace(normalizePunctuation(display))
for _, sep := range []string{"·", ""} {
    if idx := strings.Index(display, sep); idx >= 0 {
        return strings.TrimSpace(display[:idx])
    }
}
```
由于分隔符已经被移除,这段逻辑永远不会生效,对 `"·"`/`"・"` 进行截断的行为等同于被禁用,从而改变了之前实现的行为。

可以考虑在调用 `normalizePunctuation` 之前先按这些分隔符拆分,或者调整 `normalizePunctuation` 使其保留这些分隔符,并依赖这里的显式拆分逻辑。
</issue_to_address>

### Comment 2
<location path="agent/go-service/essencefilter/matchapi/matchapi_test.go" line_range="30-39" />
<code_context>
+func TestMatchOCR_EN_ExactMatch(t *testing.T) {
</code_context>
<issue_to_address>
**suggestion:**`TestMatchOCR_EN_ExactMatch` 中复用 `newEngineForTestLocale`,以避免重复编写初始化逻辑。

这个测试仍然重复了 `FindDefaultDataDir` + `NewEngineFromDirWithLocale` 的逻辑。请使用 `engine := newEngineForTestLocale(t, LocaleEN)`,这样 engine 的初始化就能保持 DRY,并且未来对 engine 构造方式的变更可以在所有测试中保持一致。
</issue_to_address>

### Comment 3
<location path="agent/go-service/essencefilter/matchapi/matchapi_test.go" line_range="427" />
<code_context>
+		{
+			name:   "EN with noisy suffix",
+			locale: LocaleEN,
</code_context>
<issue_to_address>
**suggestion (testing):** 扩展多语言模糊匹配测试,使其除了断言 `MatchExact` 的 kind 外,也断言 engine 的 locale 或本地化的 reason。

既然这个测试已经覆盖了多语言后缀处理,那么也可以顺便验证 locale 的串联是否正确。除了断言 `res.Kind == MatchExact` 之外,请再断言 `engine.Locale() == tt.locale`,或者断言 `res.Reason` 以每个 locale 预期的本地化前缀开头。这样可以暴露出 engine 使用了错误 locale 创建、或 reason 生成忽略了 engine locale 的情况。
</issue_to_address>

### Comment 4
<location path="agent/go-service/essencefilter/matchapi/matchapi_test.go" line_range="404" />
<code_context>
 	})
 }
+
+func TestNormalizeInputForMatch_ENAliases(t *testing.T) {
+	got := NormalizeInputForMatch("heat dmg boos", LocaleEN)
+	want := "heat damage boost"
</code_context>
<issue_to_address>
**suggestion (testing):** 为 JP/KR/CN/TC 以及标点添加归一化测试,以覆盖更多 `NormalizeInputForMatch` 分支。

当前只覆盖了 EN alias 的路径。由于 `NormalizeInputForMatch` 现在对汉字(CN/TC)、JP、KR 和标点有不同的逻辑,请添加以下测试:
- 确认 CN/TC 输入会剥离非汉字字符;
- 验证 JP/KR 会保留预期的字符范围(平假名/片假名/韩文),并丢弃其他字符;
- 检查全角标点/分隔符(如 `````·``/`)会被一致地归一化。
这将覆盖 `normalizeForMatch*``normalizePunctuation` 中新增的分支,并更好地防止回归。

建议实现如下:

```golang
func TestNormalizeInputForMatch_ENAliases(t *testing.T) {
	got := NormalizeInputForMatch("heat dmg boos", LocaleEN)
	want := "heat damage boost"
	if got != want {
		t.Fatalf("NormalizeInputForMatch EN mismatch, got %q want %q", got, want)
	}
}

func TestNormalizeInputForMatch_CnTcStripsNonHan(t *testing.T) {
	t.Run("CN strips non-Han", func(t *testing.T) {
		got := NormalizeInputForMatch("abc 火焰 123 ダメージ boost 攻击!!", LocaleCN)
		want := "火焰 攻击"
		if got != want {
			t.Fatalf("NormalizeInputForMatch CN Han filtering mismatch, got %q want %q", got, want)
		}
	})

	t.Run("TC strips non-Han", func(t *testing.T) {
		got := NormalizeInputForMatch("test 火焰 123 ダメージ 攻擊!!", LocaleTC)
		want := "火焰 攻擊"
		if got != want {
			t.Fatalf("NormalizeInputForMatch TC Han filtering mismatch, got %q want %q", got, want)
		}
	})
}

func TestNormalizeInputForMatch_JpKeepsJapaneseScripts(t *testing.T) {
	// Expect Hiragana, Katakana, and Kanji (Han) to be preserved while Latin/punctuation are removed or normalized.
	got := NormalizeInputForMatch("ひらがな カタカナ 漢字 ABC123!", LocaleJP)
	// Depending on the implementation, spaces between script runs may be normalized;
	// this expectation assumes they are preserved as single spaces.
	want := "ひらがな カタカナ 漢字"
	if got != want {
		t.Fatalf("NormalizeInputForMatch JP script filtering mismatch, got %q want %q", got, want)
	}
}

func TestNormalizeInputForMatch_KrKeepsHangul(t *testing.T) {
	got := NormalizeInputForMatch("한글 Hangul 테스트 123!!", LocaleKR)
	want := "한글 테스트"
	if got != want {
		t.Fatalf("NormalizeInputForMatch KR script filtering mismatch, got %q want %q", got, want)
	}
}

func TestNormalizeInputForMatch_PunctuationNormalization(t *testing.T) {
	// Full-width and separator punctuation should be normalized consistently
	input := "heat:damage・boost·test/ok"
	got := NormalizeInputForMatch(input, LocaleEN)
	want := "heat damage boost test ok"
	if got != want {
		t.Fatalf("NormalizeInputForMatch punctuation mismatch, got %q want %q (input %q)", got, want, input)
	}
}

func TestMatchOCR_MultilingualFuzzyExact(t *testing.T) {

```

如果实际归一化行为略有不同(例如,多重空格的折叠方式不同,或者对汉字在不同 locale 下有不同处理),请调整 `want` 字符串以匹配现有的 `normalizeForMatch*``normalizePunctuation` 实现。另外,请确保 `LocaleCN``LocaleTC``LocaleJP``LocaleKR` 是代码库中实际使用的 locale 标识符;如果命名不同,请在测试中使用相应的常量进行更新。
</issue_to_address>

Sourcery 对开源项目是免费的——如果你喜欢我们的评审,请考虑分享它们 ✨
帮我变得更有用!请对每条评论点 👍 或 👎,我会根据你的反馈改进评审质量。
Original comment in English

Hey - I've found 4 issues, and left some high level feedback:

  • In skillCoreCandidate you call normalizePunctuation before searching for separators "·"/"・", but normalizePunctuation already replaces those with spaces, so the separator-based split will never trigger; consider reordering or adjusting normalization to preserve the separator until after the split.
  • The new locale-specific normalization helpers (e.g. normalizeStopwordsForLocale, normalizeSimilarIfLocale) repeatedly call NormalizeInputLocale; you could normalize the locale once per code path and pass the canonical value through to avoid redundant work and make the call sites clearer.
Prompt for AI Agents
Please address the comments from this code review:

## Overall Comments
- In `skillCoreCandidate` you call `normalizePunctuation` before searching for separators `"·"`/`"・"`, but `normalizePunctuation` already replaces those with spaces, so the separator-based split will never trigger; consider reordering or adjusting normalization to preserve the separator until after the split.
- The new locale-specific normalization helpers (e.g. `normalizeStopwordsForLocale`, `normalizeSimilarIfLocale`) repeatedly call `NormalizeInputLocale`; you could normalize the locale once per code path and pass the canonical value through to avoid redundant work and make the call sites clearer.

## Individual Comments

### Comment 1
<location path="agent/go-service/essencefilter/matchapi/util.go" line_range="148-151" />
<code_context>
 	return utf8.RuneCountInString(s)
 }

+// skillCoreCandidate strips game UI suffix after a separator (e.g. rank/size) for matching.
+func skillCoreCandidate(display string, locale string) string {
+	display = strings.TrimSpace(normalizePunctuation(display))
+	for _, sep := range []string{"·", "・"} {
+		if idx := strings.Index(display, sep); idx >= 0 {
+			return strings.TrimSpace(display[:idx])
</code_context>
<issue_to_address>
**issue (bug_risk):** normalizePunctuation removes the separators before skillCoreCandidate searches for them, breaking the intended splitting behavior.

`normalizePunctuation(display)` replaces both `"·"` and `"・"` with spaces, but you then look for those same separators to trim UI suffixes:

```go
display = strings.TrimSpace(normalizePunctuation(display))
for _, sep := range []string{"·", ""} {
    if idx := strings.Index(display, sep); idx >= 0 {
        return strings.TrimSpace(display[:idx])
    }
}
```
Since the separators are gone, this logic never runs and trimming at `"·"`/`"・"` is effectively disabled, changing behavior from the previous implementation.

Consider either splitting on these separators before calling `normalizePunctuation`, or updating `normalizePunctuation` to preserve them and relying on this explicit splitting instead.
</issue_to_address>

### Comment 2
<location path="agent/go-service/essencefilter/matchapi/matchapi_test.go" line_range="30-39" />
<code_context>
+func TestMatchOCR_EN_ExactMatch(t *testing.T) {
</code_context>
<issue_to_address>
**suggestion:** Reuse `newEngineForTestLocale` in `TestMatchOCR_EN_ExactMatch` to avoid duplicated setup logic

This test still duplicates the `FindDefaultDataDir` + `NewEngineFromDirWithLocale` logic. Please use `engine := newEngineForTestLocale(t, LocaleEN)` so engine setup stays DRY and future changes to engine construction apply consistently across tests.
</issue_to_address>

### Comment 3
<location path="agent/go-service/essencefilter/matchapi/matchapi_test.go" line_range="427" />
<code_context>
+		{
+			name:   "EN with noisy suffix",
+			locale: LocaleEN,
</code_context>
<issue_to_address>
**suggestion (testing):** Extend multilingual fuzzy test to also assert the engine locale or localized reason, not only `MatchExact` kind

Since this test already covers multilingual suffix handling, it would be useful to also validate locale wiring. In addition to `res.Kind == MatchExact`, please assert either `engine.Locale() == tt.locale` or that `res.Reason` starts with the expected localized prefix per locale. That would surface cases where the engine is created with the wrong locale or where reason generation ignores the engine’s locale.
</issue_to_address>

### Comment 4
<location path="agent/go-service/essencefilter/matchapi/matchapi_test.go" line_range="404" />
<code_context>
 	})
 }
+
+func TestNormalizeInputForMatch_ENAliases(t *testing.T) {
+	got := NormalizeInputForMatch("heat dmg boos", LocaleEN)
+	want := "heat damage boost"
</code_context>
<issue_to_address>
**suggestion (testing):** Add normalization tests for JP/KR/CN/TC and punctuation to cover more `NormalizeInputForMatch` branches

This only exercises the EN alias path. Since `NormalizeInputForMatch` now has distinct logic for Han (CN/TC), JP, KR, and punctuation, please add tests that:
- confirm CN/TC input strips non-Han characters;
- verify JP/KR keep the expected script ranges (Hiragana/Katakana/Hangul) and drop others;
- check that full-width punctuation/separators (e.g., ``, ``, `·`, `/`) are normalized consistently.
This will cover the new branches in `normalizeForMatch*` and `normalizePunctuation` and better protect against regressions.

Suggested implementation:

```golang
func TestNormalizeInputForMatch_ENAliases(t *testing.T) {
	got := NormalizeInputForMatch("heat dmg boos", LocaleEN)
	want := "heat damage boost"
	if got != want {
		t.Fatalf("NormalizeInputForMatch EN mismatch, got %q want %q", got, want)
	}
}

func TestNormalizeInputForMatch_CnTcStripsNonHan(t *testing.T) {
	t.Run("CN strips non-Han", func(t *testing.T) {
		got := NormalizeInputForMatch("abc 火焰 123 ダメージ boost 攻击!!", LocaleCN)
		want := "火焰 攻击"
		if got != want {
			t.Fatalf("NormalizeInputForMatch CN Han filtering mismatch, got %q want %q", got, want)
		}
	})

	t.Run("TC strips non-Han", func(t *testing.T) {
		got := NormalizeInputForMatch("test 火焰 123 ダメージ 攻擊!!", LocaleTC)
		want := "火焰 攻擊"
		if got != want {
			t.Fatalf("NormalizeInputForMatch TC Han filtering mismatch, got %q want %q", got, want)
		}
	})
}

func TestNormalizeInputForMatch_JpKeepsJapaneseScripts(t *testing.T) {
	// Expect Hiragana, Katakana, and Kanji (Han) to be preserved while Latin/punctuation are removed or normalized.
	got := NormalizeInputForMatch("ひらがな カタカナ 漢字 ABC123!", LocaleJP)
	// Depending on the implementation, spaces between script runs may be normalized;
	// this expectation assumes they are preserved as single spaces.
	want := "ひらがな カタカナ 漢字"
	if got != want {
		t.Fatalf("NormalizeInputForMatch JP script filtering mismatch, got %q want %q", got, want)
	}
}

func TestNormalizeInputForMatch_KrKeepsHangul(t *testing.T) {
	got := NormalizeInputForMatch("한글 Hangul 테스트 123!!", LocaleKR)
	want := "한글 테스트"
	if got != want {
		t.Fatalf("NormalizeInputForMatch KR script filtering mismatch, got %q want %q", got, want)
	}
}

func TestNormalizeInputForMatch_PunctuationNormalization(t *testing.T) {
	// Full-width and separator punctuation should be normalized consistently
	input := "heat:damage・boost·test/ok"
	got := NormalizeInputForMatch(input, LocaleEN)
	want := "heat damage boost test ok"
	if got != want {
		t.Fatalf("NormalizeInputForMatch punctuation mismatch, got %q want %q (input %q)", got, want, input)
	}
}

func TestMatchOCR_MultilingualFuzzyExact(t *testing.T) {

```

If the actual normalization behavior differs slightly (for example, if multiple spaces are collapsed differently or if Kanji is treated differently per locale), adjust the `want` strings to match the existing `normalizeForMatch*` and `normalizePunctuation` implementations. Also ensure that `LocaleCN`, `LocaleTC`, `LocaleJP`, and `LocaleKR` are the correct locale identifiers used elsewhere in the codebase; if they are named differently, update the tests to use the appropriate constants.
</issue_to_address>

Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

该 PR 为 EssenceFilter 增加多语言(CN/TC/EN/JP/KR)输入与匹配能力,覆盖任务选项、pipeline attach、匹配引擎数据加载/归一化以及用户提示信息本地化,以修复繁中等非 CN 场景下的匹配失败问题(#1036)。

Changes:

  • 在任务配置中新增 input_language 选项,并在 EssenceFilter / AutoEssence(战后筛选) 的 pipeline attach 中透传该参数。
  • matchapi 引擎支持按 locale 加载技能池/武器显示名,并对 OCR 文本进行按语言归一化与更健壮的模糊匹配,同时输出可选的匹配 trace。
  • 增加多语言相关测试用例与文档说明;更新部分 pipeline 识别模板资源。

Reviewed changes

Copilot reviewed 26 out of 27 changed files in this pull request and generated 1 comment.

Show a summary per file
File Description
assets/tasks/EssenceFilter.json 增加“游戏语言”选项并通过 pipeline_override 写入 EssenceFilterInit.attach.input_language
assets/tasks/AutoEssence.json 战后筛选新增语言选项并写入 EssenceFilterAfterBattleInit.attach.input_language
assets/resource/pipeline/EssenceFilter/EntryAndInit.json 更新“是否在基质页”识别模板与 ROI/阈值
assets/resource/pipeline/EssenceFilter.json 更新初始化识别模板与 ROI/阈值
assets/resource/pipeline/AutoEssence/EssenceFilterAfterBattle.json 在默认 attach 中新增 input_language 字段
assets/resource/image/EssenceFilter/EssenceTabChoose.png 新增用于页签选中态识别的模板图
assets/misc/locales/zh_tw.json 增加语言选项与战后语言选项的本地化文案
assets/misc/locales/zh_cn.json 同上(简中)
assets/misc/locales/ko_kr.json 同上(韩文)
assets/misc/locales/ja_jp.json 同上(日文)
assets/misc/locales/en_us.json 同上(英文)
assets/data/EssenceFilter/matcher_config.json 调整 EN 后缀停用词配置以提升英文 OCR 容错
agent/go-service/essencefilter/types.go 在运行选项中新增 InputLanguage 字段并对外暴露 JSON key input_language
agent/go-service/essencefilter/state.go RunState 增加 InputLanguage 缓存(归一化后的 locale)
agent/go-service/essencefilter/options_resolve.go 支持解析/合并 input_language 选项并设置默认值
agent/go-service/essencefilter/ocr_utils.go 移除旧的中文清洗逻辑,交由 matchapi 统一处理
agent/go-service/essencefilter/matchapi/util.go 新增按 locale 的归一化、后缀处理与原因文案生成等工具函数
agent/go-service/essencefilter/matchapi/matcher.go 匹配流程改为 locale-aware,并加入可选 match trace 日志
agent/go-service/essencefilter/matchapi/matchapi_test.go 增加 EN alias 与多语言 fuzzy exact 的测试覆盖
agent/go-service/essencefilter/matchapi/locale.go 新增 locale 常量与规范化函数
agent/go-service/essencefilter/matchapi/loader.go loader 支持按 locale 加载技能池/武器显示名与 stopwords 规范化
agent/go-service/essencefilter/matchapi/engine.go 引擎构造支持 NewEngineFromDirWithLocale,并增加 trace 开关
agent/go-service/essencefilter/matchapi/README.md 文档补充 locale 用法与与 pipeline 参数对齐说明
agent/go-service/essencefilter/i18n.go 将部分 UI/提示信息按 locale 本地化输出
agent/go-service/essencefilter/actionsAfterBattle.go 战后筛选动作按 locale 构建引擎并输出匹配结果
agent/go-service/essencefilter/actions.go Init/匹配/提示输出改为使用 locale-aware 的引擎与 i18n 文案
agent/go-service/essencefilter/README.md 更新数据流说明,补充 input_language 与 locale 引擎构建
Comments suppressed due to low confidence (1)

agent/go-service/essencefilter/actionsAfterBattle.go:60

  • 这里对数据目录解析/引擎创建/MatchOCR 出错时直接 panic,会导致 go-service 进程崩溃(战后筛选属于可选能力,失败应降级而不是炸进程)。建议改为用 zerolog 记录错误(带上 component/step/locale/node),并 return false 或走一个“跳过/关闭详情”的 OverrideNext 分支来安全结束该物品处理。
	dataDir, err := matchapi.FindDefaultDataDir()
	if err != nil {
		panic(fmt.Errorf("essencefilter data dir: %w", err))
	}
	engine, err := matchapi.NewEngineFromDirWithLocale(dataDir, locale)
	if err != nil {
		panic(err)
	}

	res, err := engine.MatchOCR(ocr, opts)
	if err != nil {
		panic(err)
	}

@Joe-Bao Joe-Bao changed the title Feat/international essence feat:international essence Mar 22, 2026
@Daydreamer114 Daydreamer114 changed the title feat:international essence feat: international essence Mar 23, 2026
},
},
{
name: "JP with suffix",
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

这种也太💩了吧,我觉得还是依赖加载资源吧)

还是得搞 resource_en 这种,但里面只放一些 custom_reco_param

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

这鬼东西是中途的测试文件,忘记除掉了,要不我删掉?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

这种也太💩了吧,我觉得还是依赖加载资源吧)

还是得搞 resource_en 这种,但里面只放一些 custom_reco_param

实际suffix,我是通过外部脚本扒出来的,在外源的json里。

case LocaleJP:
return "完全一致"
case LocaleKR:
return "정확 일치"
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

那这些也一样啊)

Copy link
Copy Markdown
Contributor Author

@Joe-Bao Joe-Bao Mar 23, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

忘记问了,就是,go的focus输出i18n怎么处理,做成外源性的json?因为应该没办法从mxu那边读language吧

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

感觉还是跟着 resource 走比较好,go 就不用关心语言了,语言由 pipeline 控制(比如 resource_en 里重写某个 focus 值换成英语的,go 里只负责调用这个 focus)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

感觉还是跟着 resource 走比较好,go 就不用关心语言了,语言由 pipeline 控制(比如 resource_en 里重写某个 focus 值换成英语的,go 里只负责调用这个 focus)

我觉得不太符合我们当前的structure,我们en都已经被扬了,现在的架构更加倾向于就分adb和pc。而且go有时候有复杂输出,类似地点总结,基质总结等等,需要调用相关数据,纯粹的override pipeline没法处理这种情况。理论上i18会舒服一点,但是go没法调用,也无法得知mxu那边的语言设置。(我们有这个接口吗?)
总之我先把这些迁移到外部的i18n json?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

感觉还是跟着 resource 走比较好,go 就不用关心语言了,语言由 pipeline 控制(比如 resource_en 里重写某个 focus 值换成英语的,go 里只负责调用这个 focus)

这个需要po个issue讨论一下吗?我觉得现在架构下,本质其实不太分语言resource了,因为end是全球同步更新的。

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

也有道理,那就只用区分 ui language?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

感觉可以开个 issue 讨论下,如果是 go 来做一个 ui language 的输出,也应该有一个统一的封装,每个语言一个 json 这种,这样一堆 if else return 总归是不太好

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

这个 PR 要先 merge 吗,等讨论完方案再重构?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

这个 PR 要先 merge 吗,等讨论完方案再重构?

额,我先把不必要的测试文件和i18迁移出去?保持整洁?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

也有道理,那就只用区分 ui language?

True,这点很尴尬的在于go那边的逻辑,传统pipeline其实已经不再需要不同的language resource了,但是go或者cpp agent:
1.他们的逻辑基本是基于中文游戏UI,没有那么轻易做全球化,这个或许直接在原本基础上做全球化是一个好选择(类似这个PR一样)
2.他们的输出focus需要获取mxu ui的language,需要i18,但是没有相对接口
主要是这个两个。

@Joe-Bao Joe-Bao requested a review from MistEO March 23, 2026 10:07
@MistEO MistEO merged commit af3bcda into v2 Mar 23, 2026
18 checks passed
@MistEO MistEO deleted the feat/internationalEssence branch March 23, 2026 10:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

爆破單元的基質不會被篩選鎖定

3 participants