Orchardcore: Translate a dynamic content

[hishamco]

This is so hot!! I'm interested to make a prototype for it. The case here that there are many dynamic strings are not localization such as content definition display name, admin menu .. etc. We need to provide a way to localise them without breaking the current sites or database mechanism

[sebastienros]

Have you watched the most recent meeting where I explained the two potential designs, and the second one more specifically that I think is better? Meaning having a screen that shows all the detected dynamically localized strings and organizes them in categories?

[hishamco]

Yep I saw the latest meeting it was interested .. I like your idea may be I add some if there's

[sebastienros]

To detect the missing localized strings, we need a custom interface (like IStringLocalizer and IHtmlLocalizer) like IDynamicStringLocalizer. By calling this service for dynamic strings, we can do

D["The content is {ContentType}", typeDefinition.ContentType]

We can let the user enter custom strings, and we also can create translation strings providers that can tell the admin page what strings are available. For instance, ContentTypeTranslationProvider which would return all content types, for the "ContentType" category.

[hishamco]

The current implementation is return the same localization string if its missing which is the default behavior AFAIK in AspNetCore, so we can use LocalizedString.ResourceNotFound property to collect the missing resources in ContentTypeDefinitionDataLocalizer and list them in the admin per content type

[hishamco]

According to my talk with Seb in gitter the new design for dynamic localization will be:

1- Designing dynamic localization infrastructure APIs

• [x] Create new localizer interface similar to IStringLocalizer and IHtmlLocalizer, let us say IDataLocalizer or IDynamicStringLocalizer
• [x] Add ILocalizationDataProvider as a contract for providing the localization strings that will come from different places: content types, content fields .. ect

2- Implementing localization strings providers
The content for this localizer would be only for strings that are provided dynamically in the admin, like the content type names, the dynamic menu items, the field names (anything that is entered by a user)

• [ ] There will be a ContentTypeLocalizationDataProvider that will get all the available content types, and return them as string, same for content field names, admin menu items ... ect
• [x] Localizer isn't HTML encoded
• [x] Resolve the localizer by inject it in the views
• [ ] Render the name of a content type - and others - by calling @T["This is a content type named {0}", D[contentType.Name"]]

3- Defining the localization strings
As a translator, I want to be presented this list of strings, and their context, such that I can provide translations for each "supported culture"

• [ ] Ability to define the localization for these strings
  and ideally from the admin itself
• [ ] Create a screen in the admin that resolves all the implementations of this interface, let's call it ILocalizationDataProvider and display these in the screen
• [ ] Data Localization screen will display all these strings, and TextBoxes for each culture
• [ ] For the pluralization, in the editor you just need to be able to add multiple texboxes for each string
• [ ] Store the result of these text boxes in the database and we feed them in the DataLocalization implementation

4- Loading & Storing the localization strings
The admin screen is one way to provide the strings, but:

• [ ] We'll need them in the database
• [ ] We'll need export/import steps

@sebastienros is there anything you need to add or shall I share my thought about the above points if there's?

[sebastienros]

Some clarifications:

• ContentTypeLocalizationDataProvider is only to provide the list of values that need to be translated, it's confusing that you mention it in your first section. But it's reassuring that you mention the actual interface (ILocalizaationDataProvider) in point 3
• "Localizer is HTML encoded". No, it is not. It's one similar to StringLocalizer that is not HTML encoded. When I mentioned it I just said that because we'll be in Razor, the resulted string will be html encoded automatically, by Razor.
• Correcting one of my previous comments, if we need to use a dynamic localization as part of a translated string, this will be done like this: @T["This is a content type named {0}", D[contentType.Name"]] where T is an IHtmlLocalizer and D is a DataLocalizer.
• Like any localizer, if the localization of a string is not defined, it will output the passed value.

[hishamco]

ContentTypeLocalizationDataProvider is only to provide the list of values that need to be translated

You're right, seems I add it in the wrong place, it nothing but an implementation details to provide a list of content types to be translated

"Localizer is HTML encoded". No, it is not

It's my fault I forgot to say "Not" :)

if we need to use a dynamic localization as part of a translated string, this will be done like this: @T["This is a content type named {0}", D[contentType.Name"]] where T is an IHtmlLocalizer and D is a DataLocalizer.

Right, seems what I mention is the part to use the data localization only

thanks a lot of your clarification, I already started one a PR for this, I will keep you on the loop ...

[jrestall]

I'm really excited about this functionality. I'm thinking I'll be able to use the new admin screens to localize the text in my ReactJS site by making the localized strings available via GraphQL.

[sebastienros]

@jrestall should be doable, you'll have to provide the PR for the graphql support ;)

[sebastienros]

For the editor view, I assume we should not care about plurals as these are only single properties. Same in the API. So very simple, like StringLocalizer.

[hishamco]

I assume we should not care about plurals as these are only single properties

While we are working on a dynamic data we can't expect what the plurals form are, unless we 're sure there's no case that requires a pluralization

[hishamco]

I'm thinking I'll be able to use the new admin screens to localize the text in my ReactJS site by making the localized strings available via GraphQL.

@sebastienros is that mean we're not rely on the database only? while the localization string could come from many data sources

[jrestall]

I'm thinking I'll be able to use the new admin screens to localize the text in my ReactJS site by making the localized strings available via GraphQL.

@sebastienros is that mean we're not rely on the database only? while the localization string could come from many data sources

No, I don't think so. I'll use a tool to scan the ReactJS codebase for strings and then output them to a recipe file so that they can be imported to the database.

[hishamco]

Sounds good

[hishamco]

IMHO the caching in IDataLocalizer will be an issue here unless we are doing sort of cache invalidation mechanism

[hishamco]

@sebastienros what's the plan for this? should be a part of 1.0.0 release or not