Activities of "manuel"

Maybe too late, but if you want to improve your code you can:

public IndexControllerBase : AbpController
{
    protected override void Initialize(RequestContext requestContext)
    {
        // inject with IOC the service
       // happily use the service :)
        base.Initialize(requestContext);
    }
}

But, answering your question:

Can't we use AbpController.SettingManager in Constructor of ControllerBase?

The service needs to be resolved and injected in some way, be careful when using services in the constructor, the services that depend on session specifics could not work fine there.

Hello,

thanks for considering my ideas :)

Regarding your affirmation:

Actually localization is not limited by xml/json files, you can store localized texts in AbpLanguageTexts table. Module Zero already implements it.

I want to refer to this piece of documentation here [http://www.aspnetboilerplate.com/Pages/Documents/Zero/Language-Management]):

Note On Existing XML Localization Sources Do not delete your XML localization files and source configuration code. Because, these files are used as fallback source and also all localization keys are obtained from this source.

If this is true: >and also all localization keys are obtained from this source. then it's possible that the dependency could exist, if not, please update the documentation.

But, if the dependency exists I'll look at the source code to check how tight is the db localization implementation with the "source file based" localization system implementation and let you know.

Regarding your affirmation:

But the problem with your case here is, if you add a new localized text at runtime, you need to restart your app, otherwise you will not be able to access newly added localized text.

Decoupling the thing as explained could be possible to rely on the db to interrogate the keys, additionally if the key is missing in the db we can have a chance on the files. Doing this:

1. You can only persist the settings through the application because of the cache
2. You can ad "new" keys at runtime
3. Keep the base localization services as is

Regarding your affirmation:

Content localization and application localization are two different concept and I couldn't be sure which is convinient for your need, that's way I offered you that solution.

Your solution to my specific problem is valid and good to go, what I'm proposing is instead of going through that way I can use that time to improve this part in the Abp saga.

About the differences between Content vs Application localization, I'm thinking at the emails, sms and other stuff as a presentation layer where the language and formatting depends on the configured language for that user and/or the tenant, from this point of view I think "all this together with the views" all of them are the same thing.

There's a one more thing on this (but I think this cannot be here): "other than the UI Culture introduce the Culture itself for formatting", we can discus this in another topic if interested, let me know please.

Hello,

Thanks for the reply.

I think this could be more than a table, the Localization system is a complete solution.

The "Module Zero - by tenant, db localization" is limited by the dependency on the xml/json files, I think unnecessary, instead of developing a totally new solution I can contribute with the framework removing this dependency and implementing the CRUD and other related services, what do you think, could be? or maybe there's a reason to leave it as is?.

Thank you in advance,

Regards,

Manuel