On 3/14/19 4:00 AM, Vincent Repain wrote:
> - it appears that the use of browser locales hasn't been (yet?)
> implemented in uPortal or has been deactivated, and that the portal
> only uses a parameter (up_locale or something like that) or users
> defined locales to choose a language. Could you confirm this ?
I'm not certain of the answer to this question, sorry. Personally, I
have never had an opportunity to work on a "real" uPortal implementation
in which the UI appears in a language other than English. (I would very
much like to have that opportunity.)
I know there's a property you can add to uPortal.properties or
global.properties that will convert the UI to a language of your
choosing. I have tested & demonstrated that capability.
> - I understand that data internationalization is achieved by filling
> the up_portlet_def_mdata. Is there a way to fill this table by using
> adequate parameters in portlet-definition files, other than by using
> the translator portlet UI or filling directly the up_portlet_def_mdata
> table with sql requests ?
Based on what I know -- which probably isn't enough, when it comes to
i18n -- I suspect we'd be better off removing the up_portlet_def_mdata
table and the code that uses it.
Text content in data can be made non-English through Import/Export: if
you provide data XML files in French/German/etc, the content they define
will appear in French/German/etc when it appears in the portal.
Text content defined in the source code (everything besides data) can be
internationalized in the messages.properties files.
As long as you're not trying to offer *the same* content in *multiple
languages* at the same time, those 2 strategies should cover it.
If you _are_ trying to support multiple languages in the same portal, it
gets tougher. I know Christian C. has a very clever card component that
can offer the same content in multiple languages.
On 3/15/19 2:17 AM, Julien Gribonvald wrote:
> the goal is to purpose a multilingual portal, not partially and so not
> only with datas available in one language. For me the only one part
> missing in the portal is on datas that everyone should have to
The big challenge is that you will have to organize separate content for
each supported language -- there's no way around that.
> @Drew in non-English speaking communities we have good acknowledge on
> how work i18n, trust me ;-) !
That's good to hear!
> In my mind the pointed table could provide the persistent part of a
> such thing, but there is a development to do before to be able to use
> it. Expect if someone see an other way ?
Given that you must provide bespoke content for each language, it seems
to me that the easiest way to handle it would be to provide separate
layout fragments & portlet-definitions for each language. You could
easily make the user's language part of the criteria that determines
which fragments they get.
They could be identical (except only the language) or they could be
slightly different, depending on your needs.