feat: rename WPF editors projects

[Kryptos-FR]

PR Details

WPF projects have been moved/renamed, adding a Wpf suffix to them (to both their folder and project file).

Translation files have been refreshed (some locales had never been updated).

Note

For reviewers, the amount of files touched is huge. However, for most of them it is a simple rename without any content change. Consider focusing on the few files that do have soem changes.

Important

Before merging, all projects must compile, all tests must pass and project creation in the Game Studio should be tested.

Related Issue

Part of #3432

Types of changes

• Docs change / refactoring / dependency upgrade
• Bug fix (non-breaking change which fixes an issue)

Checklist

• All new and existing tests passed.
• I have built and run the editor to try this change out.

[xen2]

Great, looking forward to have it merged so that it's easier for you!

Question: should the current WPF project ends up keeping package ID to avoid churn on nuget.org? (keeping csproj name, or using either AssemblyName or PackageId, depending on assembly name change too)

That way, no discontinuity on nuget.org. And once Avalonia is ready, we could delete WPF and adjust Avalonia ones without Avalonia suffix.

Unless we want them side-by-side for a while? (in which case we really might want the Wpf suffix as well)
Or maybe you need to keep it that way in case some assemblies need to be split in Wpf and non-Wpf part?

[Kryptos-FR]

We want them side by side for a while. In the next PR I will introduce new projects and some have the name of previous Wpf one, like Stride.Core.Assets.Editor.

The idea is to separate code that is UI-agnostic (so most of the view models, quantum, assets and associated logic) and have only what is specific to WPF or Avalonia in their own projects.

Initially I wanted to shared that logic between the two, but our current WPF projects are too intertwined. So far only Stride.Core.Presentation was cleanly split.

In the future, if we change again to another UI framework (or even use our own), only the UI part will need to be reworked.

[xen2]

OK, sounds good

[xen2]

I think to avoid risks with upcoming release, I will soon fork master-4.4 and merge this one in master for future 4.5

[Kryptos-FR]

yes, it's probably better to target a future version

[xen2]

OK, I created master-4.4
Could you rebase your work on masterand remove conflicts please?

[Kryptos-FR]

Should be ok. Most conflicts were resolved automatically.

[xen2]

Thanks!
Please hold a bit, need to merge #3442 before master and master-4.4 diverge.