-
Notifications
You must be signed in to change notification settings - Fork 267
Resx Localization #23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
I would to keep it "simple and straightforward" rather than "IDE integration friendly" - Developers can use any tool, such as a plain text editor, to view and modify it.
Of course, maybe I'm wrong. Therefore, the PR will not be closed, and I hope that more people will participate in the discussion of which option is more reasonable.
Yes, I understand. In that particular case, VSCode has an extension to handle resx; the same is true for Rider and the same for Visual Studio, and for those who don't want to use any IDE there is an external tool. (https://github.com/dotnet/ResXResourceManager)
In any case, developers can still use a simple text editor to modify translations; there is no need to use an IDE. Resx is a simple XML file, the same as AXAML (Resource Dictionary)
I want to include more languages, and I think it is more .NET standard and easy to control translations using resx format.
Let me know any other thoughts you have.
I'm very sorry. I didn't take a closer look at the format of the Resx file. In this way, it seems that using Resx does not introduce other inconvenient problems.
One more thing, I'd like to put these translations into the Resources directory (where the rest of the project's resources are placed together). Or move the other resources from Resources directory to Assets directory?
Nice job!
@ennerperez I have a problem:
when publishing with AOT, the publish
directory has two sub directories, zh
and en
, for satellite resources (https://learn.microsoft.com/en-us/dotnet/core/extensions/create-satellite-assemblies) . I found that when I deleted these two directories directly, it had no effect on the program (localization still worked, and I didn't see anything else that affected the software).
Does it means that publishing with AOT has linked these two assemblies into the final exe file? Should I delete these two directories in final release package or not?
Looks like satelites are not requiered by the aot published version.
Yes, I think so too, but not for sure
I'm sorry, but I'm going to re-use axaml resources to manage localization. After using ResX for some time, I feel that the ResX way is very inconvenient for me in certain situations.
- Sort. If the prefixes are the same, in most cases they are translations of the same module. The order of the content of the output file is very necessary.
- In fact, ResX is relatively dependent on tool configuration. For example, the generation of Locales.Designer.cs, etc.
- I often need to switch between Windows/Linux/macOS, and sometimes add and modify Locales on one platform to quickly see if some designs are satisfactory. The ResX approach makes me feel very inconvenient, compared to the previous way of using VSCode + axaml. It's NOT as simple as I thought before
To have a simpler path to translate the app using this contains a translations file format change, to be able to use IDE resx tools or even externals like Resx Manager
image
image