question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Opening up certain methods in LocalizationProvider that are useful for others.

See original GitHub issue

Most of the code to access resource files is hidden because the methods are private. The public code revolves around retrieval of a localized resource and getting a “Compiled Resource File” meaning a dictionary of entries with best effort translated values for a given combination of resource file and locale.

I’d like to see the following methods become public:

  1. Dictionary<string, string> GetResourceFile(string resourceFile) This is one of the most basic methods in this class. It loads a given file and returns it as a dictionary.

  2. GetResourceFilename Currently there are 2 overloads. I’d like to see the most complete one public. And the current ones are missing the “ResourceType” parameter which would tell it whether it should be a Host/Portal/None file. We should have a single complete entry point where any developer can get the correct resource file name given all parameters. So a new overload that takes string resourceFileRoot, string language, PortalSettings portalSettings, CustomizedLocale resourceType as parameters.

The use case: in several cases I’ve run into this when creating translation tools for DNN. It is frustrating to have to recreate the entire class because methods have been made private that were necessary for me to access.

Issue Analytics

  • State:closed
  • Created 5 years ago
  • Comments:5 (3 by maintainers)

github_iconTop GitHub Comments

1reaction
donkercommented, May 9, 2018

True. We had that discussion. I guess that discussion is in limbo while we discuss the bigger .net core issue. It is also a much bigger change. What I’d propose is to make these changes in the current library which ultimately gets replaced in the more distant future for a new approach if we decide to go that way.

0reactions
stale[bot]commented, Nov 8, 2019

This issue has been closed automatically due to the aforementioned detection of activity. Feel free to re-open the issue if you believe it should not be closed.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Date and Time Pickers - Date localization
Date localization. Date and Time Pickers support formats from different locales. Getting started. The default locale of MUI is English (United States).
Read more >
How can I change material ui datepicker language and ...
How can I change the language of a Material-UI date picker? It doesn't seem to fully work for the whole date picker. What...
Read more >
[docs] Improve the "Getting Started" page to avoid passing ...
Before trying to render any component, you have to make sure that there is a LocalizationProvider upper in the React tree. This component ......
Read more >
LocalizationProvider - React Globalization Library
A React component which provides a localization service. Expects a language string as a property of the component. Name, Type, Default, Description. props....
Read more >
Localization Provider - Major 6 Released!
LocalizationProvider gives you option to configure fallback languages for the library. It means that provider will try to get translation in ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found