Skip to content
This repository was archived by the owner on Nov 29, 2018. It is now read-only.

AspNetCore Localization: 3 Biggest Missing Features #279

Closed
ariesdane opened this issue Sep 1, 2016 · 6 comments
Closed

AspNetCore Localization: 3 Biggest Missing Features #279

ariesdane opened this issue Sep 1, 2016 · 6 comments
Labels

Comments

@ariesdane
Copy link

  1. Ability to configure a shared resource file so that commonly translated UI terms such as "Save", "Cancel", "Required", etc can be managed in a single location rather than duplicated across multiple resource files. Meaning, that if an instance of IStringLocalizer / IViewLocalizer cannot locate an entry in the expected resource file, then the framework would check the shared resource file. The name of the shared resource file can be configured in startup and should be relative to the resource folder already configured .
  2. Allow external libraries to export their own resource files, meaning instances of IStringLocalizer / IViewLocalizer should be smart enough to look for resources corresponding to the type's assembly. Currently, resource files are always expected to be relative to the main application's configured resource folder, which makes it impossible to develop plugin systems that will provide their own translations for exported Views, ViewModels, Error Messages, etc.
  3. Support for non-compiled resource files. Currently, there's no way to update text in a resource file without recompiling the solution and deploying. Although I'm being presumptive, it's within reason to believe that 80%+ of developers would choose to deploy an updated .resx file rather than redeploy a .dll if given a choice.
@kevinchalet
Copy link

Allow external libraries to export their own resource files, meaning instances of IStringLocalizer / IViewLocalizer should be smart enough to look for resources corresponding to the type's assembly.

Agreed, this is a critical feature 👍

@joeaudette
Copy link

  1. as a workaround I implemented something to do that https://github.com/joeaudette/cloudscribe.Web.Localization
  2. I "thought" I wanted that too, but later realized that I don't care about that. Adding new languages is an infrequent task so I don't mind re-compiling, I don't want to optimize for infrequent tasks. I would rather pre-compile than to take a performance hit from the asp.net compiler needing to compile raw resx files like in the old AppGlobalResources approach. When there were a lot of supported languages and a lot of files this perf hit could be significant at startup so to me it is better to precompile.

@Eilon
Copy link
Contributor

Eilon commented Sep 14, 2016

  1. We are not planning to have a built-in feature for this, but you should be able to create your own shared resources (e.g. MyAppSharedResources.resx) and access that with the localization system. You just have to make sure you always reference those resources directly. There would be no automatic fallback between shared and un-shared resource.
  2. We think we have a solution to this, per Application parts, MissingManifestResourceException: The manifest 'Xxx.Yyy.Zzz.en.resources' was not found #281 (comment)
  3. Also no plans to implement this built-in for now.

@Eilon Eilon closed this as completed Sep 14, 2016
@Eilon Eilon added the wontfix label Sep 14, 2016
@adrien-constant
Copy link

adrien-constant commented Dec 2, 2016

I've written a custom implementation ResourceManagerWithFallbackStringLocalizer based on ResourceManagerStringLocalizer, which uses shared resources files.

I don't understand why this feature is not meant to be built-in, since it's a very common case scenario, to have a global resource file for common labels. You don't want to duplicate them. The lookup in shared resource files is only done once, since the result is cached for the next calls.

@Sandeep321
Copy link

Just to add to already listed useful features to be, please let me know if there is any solution to achieve the below.
As of now, I am required to inject the dependency of the resource file (IStringLocalizer) into my controller. What if I have multiple resource files as below:

  1. Messages-Info.en.resx
  2. Messages-Info.es.resx
  3. Messages-Warn.en.resx
  4. Messages-Warn.es.resx

Would you recommend to inject one dependency for each resource type into my controller like
MyController(IStringLocalizer<Messages-Info> infoLocalizer, IStringLocalizer warnLocalizer) {}`. In that case, what would I do if the resource tyes increase to 10 or 15?
Or is there a way to achieve this?

@hishamco
Copy link
Contributor

hishamco commented Nov 5, 2018

This issue tracker is already closed, so if there any further questions, please file an issue in the AspNetCore repo

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

7 participants