microsoft
Update the Localization Dev Doc to explain the new process
Provide a description of requested docs changes
We don't use LocProject.json or lcl files any longer, and we don't use the build-*.cmd scripts that it mentions either.
I.E. "Why don't we use resw files for diff languages like in this structure?"
Note that this example comes from official Microsoft docs.
I see it's possible to use more than one resw in the same folder. Our resw for Settings is huge, maybe we can split it. Thinking OOBE might deserve it. Or "messages", like in the example. I suppose it would go too far to give all modules a file?
For what it’s worth, i don’t think we should rename existing resource files. The localization software uses the file path as part of the primary key, so unless we tell them before we submit a renamed file they will spend effort re-localizing the “new” content. It’s not ideal…
Another question: why doesn't the localization team/software write to .resw files for each language? Like we can see in the example from Microsoft, mentioned earlier?
@crutkas after all this time I have zero idea how translation currently works. That means zero transparanty. Why don't we use (something like) Crowdin, like Files does?
I’ve explained this before. New system is different than the old but main concept is the same. We use an internal system that we must use. Stuff goes in and they magically translate it and translations are outputted at build time. If something is incorrect, we file a bug. All translations must be approved via that team. That system has a snapshot of our en-us so their system is the “source of truth”. If a en-us resource changes it is detected and translated.
this issue is about adjusting the docs against the cdpx system and tweak it for the new one when we transferred build systems.
