karaoke Interact with localizaton

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.

Apr 07 '22 13:04 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.

Apr 07 '22 14:04 andy840119

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.

Apr 08 '22 03:04 smoogipoo

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

Apr 08 '22 04:04 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.

Jun 05 '22 15:06 andy840119

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?

Jun 05 '22 23:06 smoogipoo

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.
.

Jun 06 '22 01:06 andy840119

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: https://github.com/ppy/osu-localisation-analyser/issues/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.

Jun 06 '22 04:06 smoogipoo

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

Jun 06 '22 04:06 andy840119

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.

Jun 06 '22 08:06 smoogipoo

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)?

Jun 06 '22 09:06 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?

Jun 06 '22 09:06 andy840119

Then user can add the localization to the any class matched to the Localisation/Chat/*Strings.cs.

I think it will be better to let user easy to merge the localization into single localization class.

Just to confirm, you'd basically want multiple classes to redirect to the same *Strings.cs file? So:

Class1.cs --|
            |---> Localisation/Chat/ChatStrings.cs
Class2.cs --|

Maybe.

I think that's a different task. An attribute probably fits in better there because .editorconfig is pretty "global" even though it's constrained to subdirectories. Something like:

###########################
## UI/Chat/.editorconfig ##
###########################

dotnet_diagnostic.OLOC001.class_namespace = Localisation/Chat

###########################
## UI/Chat/MyDrawable.cs ##
###########################

[LocalisationName("Chat")]
class MyDrawable
{
    // Uses localisation class: Localisation/Chat/ChatStrings.cs
}

############################
## UI/Chat/MyDrawable2.cs ##
############################

[LocalisationName("Chat")]
class MyDrawable2
{
    // Uses localisation class: Localisation/Chat/ChatStrings.cs
}

############################
## UI/Chat/MyDrawable3.cs ##
############################

class MyDrawable3
{
    // Uses localisation class: Localisation/Chat/MyDrawable3Strings.cs
}

Not sure yet. Either way I don't think this is too important.

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

As I mentioned above, probably not. It would remain as Localisation/CommonStrings.cs since it's supposed to be global. For now at least.

Maybe it's best if you write down your requirements than me guessing at it. When you want to localise something, what do you want the code fix to do?

Jun 07 '22 07:06 smoogipoo

OK I'll separate my requirements into different features and create issue in the https://github.com/ppy/osu-localisation-analyser

edited: https://github.com/ppy/osu-localisation-analyser/issues/53 https://github.com/ppy/osu-localisation-analyser/issues/54

Those two proposal are the most needed feature. Other part is just nice to have.

Jun 07 '22 12:06 andy840119

todo:

[ ] Need to check if supported in the https://github.com/ppy/osu-localisation-analyser/pull/57/files

Apr 30 '23 13:04 andy840119