ppy / osu-localisation-analyser Goto Github PK

When opening the hint in Visual Studio, the code fix is run immediately into a preview window without the user pressing "create localisation". This immediately creates the localisation file.

Example provided in ppy/osu-framework#4518

The prefix controls where the user needs to place the .resx files. For osu!, the class will be placed in osu.Game/Localisation/XStrings.cs, and the resources placed in osu.Game.Resources/Localisation/XStrings.cs.

• Properties (#48)
• Methods (#62)

See: karaoke-dev/karaoke#1265 (comment)

It should not suggest that the string is localisable when the return type is a string.

Strings in attributes must be constants.

Low priority but making an issue to document it at least.

Discussion in the karaoke-dev/karaoke#1265 (comment) with @smoogipoo
It will be better if localization string can be place into different folder in the Localisation

Here's the solution figured out by @smoogipoo:

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

It currently places the .resx files side-by-side with the Strings classes. This should be adjusted to accept and output directory.

We're currently pulling culture codes from the osu-web directory listing.

zh-tw is one of them, and the only one which looks to be unsupported by .NET. This particular localisation does not generate a zh-tw directory in the output path:

I don't know exactly how this is currently working in osu!/from where it's managing to pull the string resources, but it causes issues such as:

• The culture appears in JetBrains Rider's Localization Manager as its own entity:
  
• External rulesets can't include the zh-TW localisation (see: karaoke-dev/karaoke#1266)

Other projects, notably Humanizer and dotnet-roslyn use zh-Hans and zh-Hant in place of our zh and zh-TW locales respectively.

I can't really find any documentation on the supported culture codes - the closest I can find is documentation related to Bing maps which lists zh-Hans and zh-Hant: https://docs.microsoft.com/en-us/bingmaps/rest-services/common-parameters-and-types/supported-culture-codes, however we should be reasonably able to trust that JetBrains Rider's visualisation is accurate and that zh-TW is the only one which is unsupported.

Another request beside #53 is able to select and add the localization string to those matched localization class.

Will have more option like Like Insert the localization to the Chat/AAAStrings.cs and Insert the localization to the Chat/BBBStrings.cs

The proposal is figured out while implementing this issue.
karaoke-dev/karaoke#1365

It should be able merge into just two localization class named GeneratorStrings and DetectorStrings.
It will let the translation easy to be added if user can selected exist matched localization classes in the Localisation.

When an attribute is present such as: [LocalisableDescription(typeof(Strings), nameof(Strings.ExampleFoo))], we should make sure that the nameof() part refers to some member in the Strings type. It's enough to provide an error-level inspection without a codefix.