[Discussion] Better BaseName matching

[Compufreak345]

I think to completely support BaseName matching in JsonStringLocalizerFactory the Create-Method with a Type as input parameter should be changed to use the type:

public IStringLocalizer Create(Type resourceSource)
        {
            return this.Create(resourceSource.FullName, string.Empty);
        }

I also tried to get the matching more closely to what is mentioned in the MSDN regarding DataAnnotations localization:

Using the option ResourcesPath = "Resources", the error messages in RegisterViewModel can be stored in either of the following paths:
Resources/ViewModels.Account.RegisterViewModel.fr.resx
Resources/ViewModels/Account/RegisterViewModel.fr.resx

As I need this for my lingualization design but did not want to break the existing functionality, I tried to implement a priorized search for localization files working as you implemented it before when there is a matching folder found. This is the logic:

Search patterns when UseBaseName = true

If UseBaseName is set to true, it will be searched for lingualization files by the following order - skipping the options below if any option before matches.

• If you use a non-typed IStringLocalizer all files in the Resources-directory, including all subdirectories, will be used to find a localization. This can cause unpredictable behavior if the same key is used in multiple files.

• If you use a typed localizer, the following applies - Namespace is the "short namespace" without the root namespace:

  • If there is a folder named "Your/Namespace/And/Classname", all contents of this folder will be used.
  • If there is a folder named "Your/Namespace" the folder will be searched for all json-files beginning with your classname.
  • Otherwise there will be searched for a json-file starting with "Your.Namespace.And.Classname" in your Resources-folder.

You can see how I implemented it in my latest commit. I also extended the TestSample-Project to reflect the different ways of adding translation files.

The more strict matching from the beginning of this post might be considered as breaking change.

[AlexTeixeira]

Very good job for this point.
As I can read, is baseName is set to true we will not have the possibility to use a base json file that right ?

Si can be a problem, right now the base localizer can have a shared resource file to be shared across all page of the application.

An idea, should allow a "shared" folder that contains all string that should not be under a page or something else ?
This will let the responsibility to the user to manage his shared key and know that he can be unpredictable result.

[Compufreak345]

Very good point, this is also something I was thinking about and I also think a configurable "Shared" folder is the best/easiest to implement option. The caveat here is that we need to either iterate 2 cached dictionaries (first the explicit translation file, afterwards the shared translations) or replicate the shared strings. I prefer option 1.

In Compufreak345@c644e68 Compufreak345@eda5d5c Compufreak345@cb7cdf8 I updated the code to don't handle nested classes like being in a Namespace "[Namespace].[ParentClass].Class" and instead to use the translation file of the parent class - I found it otherwise to be impractical to create a folder (or seperate file) for each nested class.

[AlexTeixeira]

The option 1 have a big problem that's does not follow Microsoft Implementation and Guidelines.

I'm agreed that using the parent namespace file is a good thing and do not alter the Localization file structure, I prefer.

If structure is like that :
**BasePath

• Namespace.Class
  • Namespace.ParentClass.Class**

we can define if a json file exist under base path, it would be tha base parent ?

**BasePath
localization.json

• Namespace.Class
  • Namespace.ParentClass.Class**

[Compufreak345]

Do you mean we should not use the concept of a shared path and instead try to use an inheritance structure based on the folder structure? This does sound good from a user perspective, I'm just not sure what would be the best way to implement such an inheritance structure, it has the same complexities like the shared folder - either we need to store shared values redundantly (dependent on the project size this might multiply quite a bit) or we need to more deeply implement such an inheritance structure, what also might not follow Microsoft implementation and guidelines (do you have a link to those?).

For now I'll take a break from implementing more enhancements and give the current state a try in my project.

[AlexTeixeira]

Ok.

I will try to integrate all your changes in the repo as soon as possible.
After that, I think it will be more clear for me to think about a solution. I will try to found some guidelines of ask it about Localization.

Again thanks for your time and your work.

[Compufreak345]

You're welcome, also thank you for the great base I could start my fork on - it's just fair to give something back as I need to fork it for my work to comply with security requirements and stuff. Unfortunately I got some project time pressure so I can't create some clean PRs, but I hope it helps anyways ;)

[AlexTeixeira]

I integrate your changes to the repo.
The base name work as expected and all its ok for me. I added the possibility to add a .shared.json files at root path to manage some shared translations.

All changes will be available in 2.1.0-preview2

[AlexTeixeira]

Associated pullrequest #55

[AlexTeixeira]

Issues closed after no feedback