中文本地化进展艰难但顺利 / Chinese localization is progressing hard but smoothly

[ElderMeow]

已搭建本地化框架，已解决目前遇到的本地化问题，尽量采取对原项目改动最小的本地化方式。
The localization framework has been set up. Current localization issues have been resolved, adopting approaches that minimize modifications to the original project as much as possible.

已完成窗口控件的中文本地化工作，经过粗略测试，不确定是否有遗漏。
Chinese localization for windows and controls has been completed. It has undergone basic testing, though some omissions may still exist.

Check if completed:

• I have run any relevant test suites
• I, the commit author, have read the contribution terms on licensing and generative AI (last updated 2026-09-20) and am compliant

[YoshiRulz]

Firstly, thank you for working on localisation!
I don't think we should be using WinForms' built-in localisation mechanism. It's too limited and, as I'm sure you've found, annoying to work with.
There's an experimental PR #4406 which uses Fluent instead. Could you try that out and give your opinion on how easy it is, and point out any bugs or missing features?

[ElderMeow]

Hi, sorry for the confusion! This PR was created accidentally. I'm new to GitHub operations and didn't intend to submit my localization branch to the upstream repository at this stage.

I saw your comment about the Fluent experimental PR #4406. I will check it out and share my feedback later. This current resx-based Chinese localization work is still a WIP prototype on my fork. I will close this PR shortly.

[ElderMeow]

@YoshiRulz
Thanks for the response, I have evaluated the Fluent-based localization approach. Fluent only handles text translation and seemed not easy to resolve WinForms UI layout issues, so I believe using WinForms' built-in localization still necessary.

WinForms' cross-platform and localization problems. No matter what kind of localization back-end technology is adopted, these problems cannot be completely avoided. However, if the project is migrated to a modern cross-platform C# UI framework like Avalonia in the future, the `xx-XX.resx' resource file generated by Winforms' built-in localization process can still be used.

The remaining hard-coded strings in the project need to be handled separately. My plan is to wrap all hard-coded strings with a unified translation helper function. This is a necessary step, no matter which localization method is used. if the project switches to any other localization system in the future, only the internal implementation of this function needs to be replaced.

And I have solved the problem when the project uses WinForms' built-in localization mechanism. After testing, it can now work normally on Windows.

I will maintain a standalone Chinese-localized build in my fork repository. When all my localization work is completed, I will also prepare a localizable version of the project with minimal changes relative to the upstream codebase for your reference.

In fact, the only modifications necessary to enable localization are:

Necessary modification 1: Function AssemblyResolve() in Program.cs should handles CultureName. The origal project routes all DLLs through a dll/ subfolder, so satellite assemblies were never being resolved:

private static Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args)
{
	var requested = args.Name;
	lock (AppDomain.CurrentDomain)
	{
		var firstAsm = Array.Find(AppDomain.CurrentDomain.GetAssemblies(), asm => asm.FullName == requested);
		if (firstAsm != null)
		{
			return firstAsm;
		}
		// load missing assemblies by trying to find them in the dll directory
		var dllname = $"{new AssemblyName(requested).Name}.dll";
		var directory = Path.Combine(AppContext.BaseDirectory, "dll");

		// ====================== The added code ===================
		var cultureName = $"{new AssemblyName(requested).CultureName}";
		if (!string.IsNullOrEmpty(cultureName))
		{
			var fnameWithCulture = Path.Combine(directory, cultureName, dllname);
			if (File.Exists(fnameWithCulture))
			{
				return Assembly.LoadFile(fnameWithCulture);
			}
		}
		// cultureName processing completed.

		var fname = Path.Combine(directory, dllname);
		// it is important that we use LoadFile here and not load from a byte array; otherwise mixed (managed/unmanaged) assemblies can't load
		return File.Exists(fname) ? Assembly.LoadFile(fname) : null;
	}
}

Necessary modification 2: Update LogicalName for *.xx-XX.resx so the resource name matches the actual class namespace rather than the folder path:

<ItemGroup>
	<EmbeddedResource Update="**\*.zh-CN.resx">
		<LogicalName>BizHawk.Client.EmuHawk.%(Filename).resources</LogicalName>
	</EmbeddedResource>
</ItemGroup>

Missing DependentUpon entries added for resx files the project had left unlinked and so on (not more than 40 lines).

Only need to modify these two places, and a few other configurations, WinForms built-in localization on Windows goes working.