Content Studio doesn't read default phrases.properties for layout descriptor

[stanzani]

Hi,

We are working on an application whose default language is Norwegian, and the second language is English so we have:

• phrases.properties (no)
• phrases_en.properties

We are using the latest version of Content Studio (4.2.4) and the content language is set to Norsk too.

We have many layouts and content types whose descriptors contain forms that use i18n.

Even setting the User Agent (Google Chrome 105.0.5195.127 64bits) primary language as Norwegian, the strings from the default phrases.properties strings are ignored and only the ones from the English sibling are shown in the example below:

The only ways we found to make the default language work are:

1. Removing English from the browser’s language list;
2. Creating a Norwegian-specific copy of phrases.properties (phrases_no.properties) and setting Norwegian as the browser’s primary language.

If the secondary language (English) exists in any sequence of the browser’s list, the translation in the default phrases.properties is ignored.

We tested many other apps and sites we have, and this is new behavior for us.

Thanks.

Enonic version: 7.9.2
OS: Ubuntu 20.04.4 LTS

[ase]

Have tested this now. I have Norwegian Bokmål set as the main language, and I have norwegian phrases in phrases.properties and english phrases in phrases_en.properies.

Everything seems to be working as it should when it comes to localisation.

Here’s with Norwegian Bokmål as main language:

Here’s with English:

Here are translations:

Descriptor:

<content-type xmlns="urn:enonic:xp:model:1.0">
  <display-name>Selector</display-name>
  <super-type>base:structured</super-type>
  <form>
    <input name="test" type="ContentSelector">
      <label i18n="action.archiveMore">Input label</label>
      <occurrences minimum="0" maximum="0"/>
    </input>
...

phrases.properties:
action.archiveMore = Arkiver...

phrases_en.properties:
action.archiveMore=Archive...

We are using the latest version of Content Studio (4.2.4) and the content language is set to Norsk too.

Content language has no effect on localisation of texts/input labels.

[ase]

Did you find out why it didn’t work?

[stanzani]

Alan,

My browser configs are:

As I said before, the phrases.properties contains the Norge strings and the translations to English are inside the phrases_en.properties.

The Norwegian strings are shown only when I remove the English language from my configurations.

I assure two more Enonic developers and I decided to open this Issue after testing all the scenarios above (both have more experience than I have).

Thank you for your support.

[ase]

This is correct behaviour based on your browser config.

phrases.properties is used only as a fallback, only when there’s no match with any language configured in your browser.

In your case, the system goes down the list of languages until it finds “English” which you have a matching file for (phrases_en.properies) and uses it.

In other words, phrases.properties is a fallback resource bundle, not a default one.

[stanzani]

@ase

Content language does not affect localisation of texts/input labels.

Ok, so the behavior you have with Norwegian Bokmål as the main language should be the same I have with Portuguese as the main language, no?

I see we have two conflicting pieces of information here. If comparing my configuration and your configuration, since the Content language has no effect, the behavior should be the same (I believe).

If your main language is not explicitly specified and you have the English language in your list, Content Studio should then show everything in English.

Sorry for insisting, but the information is really conflicting.

[ase]

Yeah, it seems I rushed a bit the first time I commented. I used one of the same resource keys that we used in Content Studio in the test app, so instead of the one from the test app it was Content Studio’s phrase.

This time I did it properly, using a brand new resource key in the test app. Here’s my setup:

phrases.properties:

user.greeting = (no) Hei, vi er i Norsk!

phrases_en.properties:

user.greeting = (en) Hello, we're in English!

descriptor.xml

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<content-type>
  <display-name i18n="user.greeting">Text Line</display-name>
  <super-type>base:structured</super-type>
  <form>
    <input name="requiredTextLine" type="TextLine">
      <label i18n="user.greeting">Required Text Line</label>
      <occurrences minimum="1" maximum="1"/>
    </input>
  </form>
</content-type>

Browser settings:

Result:

So, my browser language is Norsk Bokmål. Content Studio shows Norwegian texts in the menu etc. because we have phrases_no.properties for Content Studio. But user.greeting phrase that comes from the test app is in English, because in the test app we have phrases_en.properties and that’s what is picked up (since there’s no phrases_no.properties in the app). phrases.properties (the fallback) is never used.

[stanzani]

Ok. Now the question became clear.

Is there any way to make the application read the phrases.properties without creating a phrases_no.properties, or else, to have a phrases_no.properties and make this file the default one? Would be very useful to avoid duplicating code and having one more strings file to manage.

Thank you!

[ase]

I don’t see how this will work. If we do it like you suggest, then the default bundle will ALWAYS be used, even if there’s another phrases_xx bundle that actually matches the user’s browser language.

You are basically forcing user to use phrases that his/her browser may not support. If you want to debug localisation for Norwegian language, then you have to add Norwegian to your browser languages.

[stanzani]

No, It is not a suggestion and is not what I would like to be possible to do.

Just close the topic.

Thanks.

[ase]

I’ll leave it open in case there will be similar questions/confusion in the future.

[stanzani]

In the new version of Next.XP they added exactly what I asked if was possible to do in Enonic, and I still think would be useful in Enonic to avoid code duplication:

Add i18n config block to next.config.js

i18n: {
    locales: ['en', 'no'],
    defaultLocale: 'en',
}

[tsi]

Hi Stanzani.

This is quite a different thing from our properties files IMHO.

We’re basically just using Next.js standard functionality. The default setting here simply implies that domain.com/ will use the “default” locale, while the others will be available on domain.com/no etc.

[stanzani]

Thomas,

The idea is the same.

Today, if we have two languages, we need 3 phrases.properties files, because to solve the problems I exposed above, one file is the fallback but is identical to one of the language files.

If we had a simple configuration to define the default language, we wouldn’t need to maintain and control a third file - identical to one of the other two - only to be the fallback.

Many other frameworks have this kind of configuration and I think it would be helpful - mainly in big projects.

But now this is only a suggestion and the door opens from the inside.

Fred og godt.

[tsi]

I’ve read through your post and see the problem, basically any language listed in the browser preference list will take presedense over the fallback?

Did you consider making English the fallback instead? Then anyone with “no” in their accept language list would get norwegian AFAIK.

[tsi]

This is how all of Content Studio works AFAIK, with English as the fallback. I guess aligning your localizations with the rest of Enonic Admin would make the most sense?

[stanzani]

Suppose I have the scenario below:

We have a site built for Middle Earth, but accessible from Pandora, so we have:

• phrases.properties (fallback and default language file in Elfic Language);
• phrases_nv.properties (Na’vi language file);

Now imagine a bilingual Elf who was born and raised speaking the Elfic language, but who has a proficient ability of reading in Na’vi language. In his browser config he will have:

• 1 - Elfic Language (default);
• 2- Na’vi (second language);

This guy never will see the site in his preferred language, despite the site supporting it, and the site will always be displayed in the Na’vi language for him.

To solve this problem the site developer should make:

• phrases.properties (fallback and default language file in Elfic Language);
• phrases_el.properties (identical to the file above, but duplicated);
• phrases_nv.properties (Na’vi language file);

The problem is that the fallback language will always be a copy of another language that the site supports.

What I asked for is a solution to avoid duplicating the default language as listed in the last situation above.

Takk!

[tsi]

I can see your point, and you have a workaround for now by duplicating the file. But, are you trying to add localization to parts of Admin, or for a site?

[stanzani]

For editor. For site we also use the i18n files but we adop another strategy.