Localization needs a redesign

[damienbod]

Hi

At present rc1, the provided localization solution does not provide a good solution for developers. I think the new ASPNET is great, but the new localization solution is really not an improvement. Judging by all the problems in rc1 for localization, this has not really been though through or the different teams don’t seem to work together.

You can find issues in all the different repos for the following problems, some closed even though the problem still exists.

• At present you cannot run a localized application from VS
• You cannot use a shared resource from a separate library.
• You are forced to use magic class names for the default localization to work.
• A shared resource requires an empty class to work per default.
• The generated resources are produced as internal classes instead of public classes which don’t work.
• No VS template exists for a Json resource instead of resx.

Direct resource dependencies are undesired, as I would like to use the resources using the DI framework.

Would it not be time to reconsider the solution? If the recommended localization is released as it is, you’re just taking away from all the other good parts of ASP.NET 5 and will frustrate many developers. The recommended new localization is not usable for my default application.

Greetings and thanks Damien

[boyarincev]

I think Json resources it's a good idea!

[TheMadKow]

👍 On Json Resources

[oliverw]

👍 I tend to agree with most points put forward by @damienbod. The amount of hoops developers have to jump through to migrate projects relying on strongly-typed .resx resources is a bit over the top.

It took me a while to figure out why a project I am supposed to migrate to MVC6 would not work just because resx resources get embedded with the wrong resource identifier if the project's default namespace differs from the project name.

The fact that the generated designer.cs defaults to making everything internal just makes everything even more painful.

[joeaudette]

From my point of view the tooling problem is the biggest problem because I think it blocks some things that are supposed to be possible but I'm not sure what is supposed to be possible.

For example maybe it is supposed to still be possible to use resx files the old way with a default resx file and designer and static access but since the tooling forces the designer class as internal it is not currently possible. Or maybe it is not supposed to be possible to use static resources anymore, it is unclear what the intention is. The lack of clarity on what is supposed to work is a problem that could be helped if there were some documentation or guidance.

I spent 2 hours yesterday installing VS 2015 update 1 in hopes that it would fix the tooling problems but it did not.

The issue about needing a class name or type to identify the resource doesn't really bother me because resx files always did have a class in the past in the designer.cs file so it doesn't seem unreasonable to me that a class is required even if we no longer use static access. Since it can be any class like HomeController or whatever many people will not need any extra class but for the case of sharing a resx file it does not bother me to need to create an empty class that the resx files will be named after. it creates no burden of maintenance and it is cleaner for me to own that class rather than have it generated like designer.cs files were.

Myself I just want to use shared resx files from a folder beneath the web app, and other than the tooling problems I do not feel blocked on that right now. Currently the ResourceManagerStringLocalizerFactory.cs does not do what I want because it doesn't work if the class that the resx file is named after is in a class library and not in the web app. But if that is not determined by the team to be a bug I can easily implement my own SharedResxStringLocalizerFactory that would behave exactly as I want it to.

My main reasons for wanting to use shared resx files is because they are easy to work with and I have some existing resx files from a previous project that I can potentially harvest and re-purpose. The most reliable translator that helped in my previous project used excel to edit the resx files he translated and that was convenient for him. Embedded resx files and satellite assemblies are much more inconvenient to work with.

use of json like in resjson might be interesting especially for localizing SPA style javascript apps but in that case I think I would lean towards more separate smaller files rather than larger shared resource files. I suppose I could also generate json on the server from the resx file if I want to keep using resx.

So from my point of view I can't really agree that a redesign is needed for localization. I would like to see more clear guidance on techniques that are supposed to work and I would like to see the tooling issues fixed.

[jerriep]

👍 Cannot add much more to what everyone else has already said, other than that I share the concerns.

[JoeOM]

Completely agreed.

Like I said in the following post aspnet/Localization#153 it is back to the drawing board on this one. RTM cannot be released without this all fixed and properly tested.

Why all this had to be picked up by the community and was not picked up by Microsoft testers is evident of lack of testing, so test more!

[jmurkoth]

These are top 4 things that I would like to see fixed before RTM

1. Localization to work as expected in Visual studio)
2. Ability to use the resource files without the need to add namespaces in the name for default to work
3. Reduce the friction and make it easier to use the shared resource files like it was before
4. Fix the resource class generator so that the classes are public( this is more of an annoyance as we need to go back and change it every time the file changes)

[DaveConsulting]

Completely agreed with damienbod. After days of spending on localizations, I couldn't find a way that works. Please consider a review on the design. I don't see this way of localization as an improvement.

[Eilon]

@DamianEdwards ping to remind you to update this issue with the changes we discussed.

[DamianEdwards]

We're making a set of changes designed to improve the usability issues people are hitting with the current localization pieces:

• Cold performance of ResourceManagerStringLocalizer is atrocious aspnet/Localization#162
• Improve usability of the request localization middleware aspnet/Localization#164
• Make the RequestLocalizationMiddleware support derivative cultures aspnet/Localization#165
• Add GetString to IStringLocalizer aspnet/Localization#166
• ResourceManagerStringLocalizerFactory should look for resource name without the application name prefix on the type name when Resources path is set aspnet/Localization#167
• Improve usability of HtmlLocalizer aspnet/Mvc#3716
• HtmlLocalizer<T> should look for resource name with or without the application name prefix aspnet/Mvc#3717
• ViewLocalizer should look for resource name with the application name prefix when LocalizationOptions.ResourcesPath is not set aspnet/Mvc#3718

We'll of course have it all working when launching from VS come RTM too (most likely in RC2 in Feb actually).

The issues regarding the use of the traditional .NET resource tooling (static class file generator, ResGen) in ASP.NET 5 projects (e.g. not being able to set the modifier to public) are also being addressed before RTM.

In addition to this, we'll have an example localized version of the VS new project template, as just seeing how these APIs are intended to be used goes a long way to helping. This is currently in progress in a branch at https://github.com/aspnet/Entropy/tree/damianedwards/loc-sample

We of course intend to document these new APIs in the future as part of the overall ASP.NET 5 documentation effort at http://docs.asp.net

Sorry for the frustration with using what we've built so far and thanks for your patience while we work through all the issues.

EDIT:

https://github.com/aspnet/Entropy/tree/dev/samples/Localization.StarterWeb

[JoeOM]

Hi Damian

Thanks for this.

I have updated the title of aspnet/Localization#153 to be more relevant to the remaining issue being discussed in there which relates to "A shared resource requires an empty class to work per default" stated by Damien above.

[damienbod]

Hi @DamianEdwards

Thanks, looks promising.

Any chance of a Json resource template?

Greetings Damien

[jmurkoth]

Thanks @DamianEdwards Looking forward to the next drop with these changes

[chemitaxis]

Thanks @DamianEdwards

[rsheptolut]

@DamianEdwards thanks for your work, but the link is not working anymore. Did you move your localization sample somewhere?

[davidfowl]

I updated his post with an updated link https://github.com/aspnet/Entropy/tree/dev/samples/Localization.StarterWeb

[rsheptolut]

@davidfowl, thank you!

[JuergenGutsch]

thanks, @davidfowl :)

[JoeOM]

Hi everyone

Localization still does not support Shared Resources using a string identifier instead of a type, so I have opened another issue.

aspnet/Localization#227