Replies: 3 comments 5 replies
|
Seems I missed this LIVE. Is there any recording? Coz I'm interesting to help on this |
|
I will publish the recording later this week |
|
I'm using the LanguageSwitcher to allow users of the site to choose what language the UI (static) labels should be shown. The site itself is English, but the sign-up forms are in English and another language that can be chosen at run-time. This is managed via Localizer[] and RESX files defined in my module. I heard in the meeting that the LanguageSwitcher will only show up for admin users. Without building two separate sites, I'd like to keep using the LanguageSwitcher control and will move it to my theme so it's available to all users. I have not upgraded to the latest oqtane, so I'll check back when I have. Hopefully I can get away with just having one site and the lables change based on user selection of the current language. |
|
@markdav-is what you are describing is UI (Static) Localization ie. the Content of the site is maintained in a single language, whereas the static labels in your forms can be displayed in multiple languages. Based on the feedback in the Community Standup I am investigating ways to allow the LanguageSwitcher to support multiple scenarios. For example:
The above logic would determine where the system should load the list of languages and how the Thread Culture cookies should be set. For Content (Dynamic) Localization the list of languages come from the Site Group, and for UI (Static) Localization they come from Language Management. If a user tried to use BOTH Content (Dynamic) Localization AND UI (Static) Localization within the same Site, the system would favor Content (Dynamic) Localization and users would need to change their UI language in their User Profile (which should be fine). This approach would provide decent backward compatibility and more flexibility. |
|
#6011 includes the changes described above. The LanguageSwitcher component has been added back to the Control Panel so there is no disruption to existing installations. |
|
When using Site Groups and defining a Localization group: 
The LanguageSwitcher component will use the group: 
When not using Site Groups and defining multiple UI languages within a site, the LanguageSwitcher component will use the Languages defined for the site. |
|
@sbwalker Thanks for the great work around localization, which I believe is a great addition for Oqtane. I can't wait to test it once it's released. Only one question, will there be any way to centrally manage localized content? For example, if I want to review all the language versions of a specific HtmlText module, do I need to go to each language site to review it there? If I'm understanding it correctly, the site group's responsibility is only notifying when a change occurs, right? |
|
@mdmontesinos correct - there will not be any side-by-side UI tools to compare localized content from different sites/languages in a single pane of glass. There is a Change Detection group which can notify the administrator when content changes on the primary language site. The notification includes details about which pages and modules changed so that a translator can make the necessary changes. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Continuing the discussion from the Oqtane Community Standup today.... specifically related to Content Localization. This topic had been raised a number of times in the past (ie. https://www.oqtane.org/blog/!/93/oqtane-developers-meeting-july-2024) and although I have always tried to provide clear guidance in this area, I am sure the latest changes in the Dev branch are confusing for some people.
To provide some context...
There are 2 distinct types of localization:
UI (Static) Localization - ability to display the static labels, help text, messages, etc... (which are part of the software itself) in different languages. For .NET this is usually implemented using static resource (RESX) files and satellite assemblies.
Content (Dynamic) Localization - ability to display user contributed/managed content in different languages. This type of content is usually stored in a database.
Oqtane has supported UI (Static) Localization since version 2.0 (2021) by allowing users to install Translation packages (for the framework and modules).
Oqtane has never provided support for Content (Dynamic) Localization but is planning to offer this capability in version 10.1.
Content (Dynamic) Localization
The Oqtane framework is comprised of many entities which are organized in a hierarchical manner ie. Site, Page, Module, etc... Each of these entities contain user contributed/managed content (ie. metadata) which needs to be localized. However, the Oqtane data model was never designed to support content in different languages within the same site. This means that all user contributed/managed content within a site must be in the same language. So how can Oqtane support Content (Dynamic) Localization?
In fact, this was a deliberate design decision. Oqtane is multi-tenant... which means that it supports multiple sites within the same installation. So each site in an installation can maintain content in a different language. Utilizing the site as the atomic grouping level for localization greatly simplifies the system architecture. It avoids having to pollute all of the lower level entities with additional language metadata. It also means that modules can support localization by default, as there is no special requirement to consider language when managing content. And since all of the existing framework features are also scoped at the site level (content search, etc...) they do not need to be modified to support Content (Dynamic) Localization.
Site Language
An additional field has been added to the Site entity to specify the language for its Content. This is managed in the Site Settings UI
User Language
A site manages Content in a single language. However, a user may want to interact with the UI in a different language (ie. Static Localization). If other translations have been installed and enabled for the site, a user should be able to choose from the list of supported languages in the User Profile. For example a site might maintain its Content in English, however it might have English and French translations installed, and a native French speaking user may choose to interact with the UI in French (even though the Content is in English).
Urls
A few different approaches can be used for managing Urls for sites in different languages:
http://www.domain.com (English site)
http://www.domain.com/fr (French site)
http://www.domain.com (English site)
http://fr.domain.com (French site)
*note that in the above examples, cookies can be shared because they use the same root domain
Site Group
A new capability has been added so that sites where are related can be grouped together. This allows the framework to determine if a site belongs to a localization group. Site Groups are managed from the Site Settings UI.
Language Management
The Admin Dashboard for a site contains a Language Management capability. Since a site only supports a single language from a content perspective (defined in Site Settings), the Language Management UI is used for defining the UI languages which users can utilize to interact with the site (ie. Static Localization).
LanguageSwitcher
This component was previously part of the Control Panel and would be displayed if multiple languages were defined in Language Management. This has now been replaced by the Language field in the User Profile. It will need to be determined if site visitors (ie. those without a user account) need the ability to choose a UI language (usually visitors are required to interact in the Content language for the site).
LanguageSelector
A new component was added to the default Oqtane theme. If a site is a member of a site group supporting localization then it will display a dropdown of languages, and when a user selects a language they will be redirected to the site matching that language.
Module-Based Custom Solutions
Some third party modules currently exist which allow a user to manage its content in multiple languages. Obviously, this is not consistent with the approach described above (ie. one language per site). And although a custom module may allow you to manage its content in multiple languages within the same site, other framework attributes such as module title and metadata, page name and metadata, site name and metadata, urls, etc... cannot be localized into multiple languages.. so these modules are only a partial localization solution and will never be capable of providing full content localization (and therefore should be avoided in most cases).
All reactions