Interact with localizaton

[andy840119]

Not really sure if other rulesets already contain translation...

What's should be done if wants to add the translation:

• Add the Localisation namespace and add the testing translate.
• See ResourceManagerLocalisationStore, need to check about is there any way to apply the localization for ruleset.
• Check how to generate the translation source file.
• See the project about how to make pull-request if has a new translation https://github.com/ppy/osu-resources.

[andy840119]

Can be separated into

Config:

• ConfigSettingsStrings
• StyleSettingsStrings
• ScoringSettingsStrings

Gameplay:

• ModeStrings(Not sure)
• GameplayStrings(Not sure)

Edit:

• LyricEditorStrings(Not sure)
• SingerEditorStrings(Not sure)
• TranslateEditorStrings(Not sure)
• EditorSetupStrings(Not sure)
• ComposerSetupString(Not sure)
• [Note] should consider about some common string, e.g: tooltip or dropdown.

[smoogipoo]

I would be interested if you are able to use https://github.com/ppy/osu-localisation-analyser. It's made for this purpose, but hasn't been tested outside of osu! yet.

Add it to your project via both:
https://github.com/ppy/osu/blob/d256bd2cc793d0ea296eea9a75ab09aa5fd92c63/osu.Game/osu.Game.csproj#L33-L36
https://github.com/ppy/osu/blob/d256bd2cc793d0ea296eea9a75ab09aa5fd92c63/.config/dotnet-tools.json#L29-L34

The first tool gives you code refactoring options at the start of non-verbatim strings (strings which don't start with @) in tools like Rider, VSCode and Visual Studio. It automatically generates the XStrings.cs files for you.

The second tool is used to generate the .resx files (run dotnet tool restore first).

• You can either place these alongside the .cs files via:
  dotnet localisation to-resx /path/to/project.csproj
• Or you can redirect them to another directory via:
  dotnet localisation to-resx /path/to/project.csproj --output /destination/directory/path
  Note that you will also need to add entries to .editorconfig to point the code refactoring tool to the correct namespace. In osu! we place our .resxs in the osu-resources project, so this can be used as a reference configuration: https://github.com/ppy/osu/blob/d256bd2cc793d0ea296eea9a75ab09aa5fd92c63/osu.Game/.editorconfig#L1-L3
  The .resx files can be imported into services like https://crowdin.com/ where others can contribute translations.

There's currently no automated tool to pull the .resx files from crowdin, but placing them alongside the existing .resxs is enough.

Everything should work with just the above, the game's already set up to support external localisations like this.

[andy840119]

Big thanks!
I might try it maybe in the next week if I have enough time👍

[andy840119]

@smoogipoo is there any suggestion about collecting the localization in this PR(#1365)?

The structure i desired in the Localisation folder might be like:

• Edit
  • Checks
    • CheckInvalidPropertyLyricsStrings
    • CheckInvalidPropertyNotesStrings
    • CheckInvalidRubyRomajiLyricsStrings
    • CheckInvalidTimeLyricsStrings
    • CheckTranslateStrings
  • Components
    • (It's a little bit complex in here)
  • Configs
    • (Structure is not sure in here)
  • Generator
  • CommonGeneratorStrings (Or GeneratorCommonStrings)
  • LanguageDetectorStrings
  • NoteGeneratorStrings
  • ImportLyric
    • (Will give each step a string class)
  • Lyrics (or LyricEditor)
    • CommonLyricEditorStrings
    • (Will give each edit mode a string class)
  • Setup
    • (Not really sure in here)
  • Singers
    • SingerEditorStrings
    • SingerEditorDetailStrings
  • Translate
    • TranslateScreenStrings or TranslateEditorStrings
  • (Not really sure how to deal with remain class now)
• Mods
  • (Not really sure should give each mode an individual localization class?)
• Overlays
  • KaraokeChangelogOverlayStrings
• Statistics
  • (Not really sure should give each statistic class a localization class?)
• UI
  • NotePlayfieldStrings.
  • HUDStrings.

[smoogipoo]

It doesn’t support that yet. What we could do is add support via either an attribute on the class or namespace forwarding in .editorconfig.

Any preference or other suggestions?

[andy840119]

Not really sure will it be the good suggestions:

• Any strategy to check the duplicated translation strings? Or even merge them?
• Will have common string in each namespace in the Localisation, like CommonLyricEditorStrings in the Lyrics namespace?
• Click to fix the string in the prefix. i guess it's generated by namespace, not really sure will it be better to always follow the namespace.
• Not really sure is this a knows issue? The return type is not the LocalisableString but it still shows the message.
  .
  

[smoogipoo]

• Any strategy to check the duplicated translation strings? Or even merge them?

Maybe I'm not understanding, but it should be doing this already. For both the class and common strings.

• Will have common string in each namespace in the Localisation, like CommonLyricEditorStrings in the Lyrics namespace?

Not sure / probably not / maybe? Let's start off with only doing something for the class strings.

• Click to fix the string in the prefix. i guess it's generated by namespace, not really sure will it be better to always follow the namespace.

The prefix is a little different. It should match where the .resx files live.

• Not really sure is this a knows issue? The return type is not the LocalisableString but it still shows the message.

Created issue: ppy/osu-localisation-analyser#52

---

Basically, what I'm envisioning is something like the following:

MyProject
|- Localisation
   |- Chat
      |- ...                        => *Strings files  <-------------------|
   |- SomeOtherLargeNamespace                                              |
      |- ...                        => *Strings files <--------------------|------------------|
|- UI                                                                      |                  |
   |- Chat                                                                 |                  |
      |- .editorconfig              => Maps to Localisation/Chat namespace |                  |
      |- ...                                                                                  |
   |- SomeOtherLargeNamespace                                                                 |
      |- .editorconfig              => Maps to Localisation/SomeOtherLargeNamespace namespace |
      |- ...
|- Resources
   |- ...

The .editorconfig files would be something like...

# Placed in the UI/Chat directory, to redirect to the Localisation/Chat directory.
dotnet_diagnostic.OLOC001.class_namespace = Localisation/Chat

Does that sound like it'd work for you?

I'd need to check but I believe .editorconfig files are merged, and the deepest level overrides settings from earlier configs, so you could place a .editorconfig in UI/ dir to redirect elsewhere for both the files in that level and sublevels that don't have their own .editorconfigs.

[andy840119]

Any strategy to check the duplicated translation strings? Or even merge them?

Sorry i didn't notice that already exist.

dotnet_diagnostic.OLOC001.class_namespace = Localisation/Chat

Seems a cool idea.
But does that means it can have more than one CommonStrings.cs in the different namespace?

Will it be able to insert the localization string to the matched namespace?
Like Insert the localization to the namespace/xxxStrings

[smoogipoo]

But does that means it can have more than one CommonStrings.cs in the different namespace?

As I said I'm not sure about this, and I think it's best for common to always go into Localisation/CommonStrings.cs. These are supposed to be used in many areas across the entire codebase, where namespacing doesn't make sense.

Will it be able to insert the localization string to the matched namespace?

Do you mean having a 3rd option in addition to the two from your screenshot?

My plan was to have "add new class localisation" always redirect to Localisation/Chat/*Strings.cs.

[andy840119]

Do you mean having a 3rd option in addition to the two from your screenshot?
My plan was to have "add new class localisation" always redirect to Localisation/Chat/*Strings.cs.

Yes
I means if user has .editorconfig like this.
Then user can add the localization to the any class matched to the Localisation/Chat/*Strings.cs.

# Placed in the UI/Chat directory, to redirect to the Localisation/Chat directory.
dotnet_diagnostic.OLOC001.class_namespace = Localisation/Chat

I think it will be better to let user easy to merge the localization into single localization class.
Or will it be better to one class(e.g: TimeTagGenerator) match to exactly one localization class(e.g: TimeTagGeneratorStrings)?

[andy840119]

But does that means it can have more than one CommonStrings.cs in the different namespace?

Will CommonStrings.cs path changed if user override the class_namespace in the .editorconfig?