Add missing localization strings

[hishamco]

I'm working to localize Oqtane in Arabic, this PR should fix all the missing localizations strings

[sbwalker]

since this is still a Draft let me know when I can merge it

[hishamco]

Sure, I'm trying to translate a full installation of Oqtane

[hishamco]

@sbwalker we ready to merge, just 2 or 3 items that I should follow into other separated small PRs:

• Localize ModuleMessage

• Localize ModuleTitle

• Localize ModuleInstance which is I don't know where it's used

[sbwalker]

We had a conversation about ModuleMessage previously and I thought we concluded that it could not be localized because it displays dynamic content? Module developers should use the AddModuleMessage() helper method as part of ModuleBase - which passes text to the ModuleInstance component and displays the message.

ModuleTitle would not be localized as its sole purpose is to display information from the database - not static content.

ModuleInstance is a component that is part of the dynamic page compositing engine. There is some static content that is displayed on various error conditions.

[hishamco]

We had a conversation about ModuleMessage previously and I thought we concluded that it could not be localized because it displays dynamic content?

Ya, we can choose one of two options:

1. Localize message inside ModuleMessage

2. Make localization outside ModuleMessage

The advantages for first option is all the resource strings will be in one file ModuleMessage.{culture}.resx, no need to localize strings outside

The advantages for the second option is the Resx files will follow the regular convention, all the resources strings will be in the place where the message are set

ModuleTitle would not be localized as its sole purpose is to display information from the database - not static content.

Aha, no need

ModuleInstance is a component that is part of the dynamic page compositing engine. There is some static content that is displayed on various error conditions.

Thanks for clarification

[sbwalker]

@hishamco if you consider the fact that Oqtane is a modular framework - and the primary development approach is to create modules EXTERNAL to the framwork - then I don't see how localizing messages inside of ModuleMessage would actually work? If an external module wants to localize their messages then isn't the only solution for localization to be managed outside of ModuleMessage? Maybe I am missing something?

[hishamco]

then I don't see how localizing messages inside of ModuleMessage would actually work?

Good point, so I think localize the strings outside will be better to support both Oqtane Framework & External modules, I think I will change how the logging is localized to follow the same principle

Thanks

[hishamco]

So let us merge this, I will push 2 other PRs for ModulesMessage and logging ASAP

[sbwalker]

@hishamco the external module perspective should always be the primary use case we consider