Content language issue (language) on specific pages

[sgrellet]

On

• the landingpage
• the description of a register entity

[sgrellet]

For example : https://data.geoscience.fr/ncl/obssup/11 be able to switch display of @en / @fr content (or see all)

[sgrellet]

Seems better to do this at the UI level and not at SparQL query level

[der]

Please could you clarify the requirement, in particular what you mean by "see all".

Currently where a property has both @en and @fr tags it both should be rendered in the property table. The current render, as illustrated by your example page isn't very clear but the latest release will render them one per line in a stable order with the language code being shown.

Then in the descriptive text at the top it is supposed to pick the correct rendering for the label and description based on the language setting of the browser. [Though I see in your example the label part of that isn't working.]

Is this the functionality you need, if we fix the bug in label choice, or are asking for an active UI control to override the browser language setting and allow interactive choice of language to render in?

[afeliachi]

We are facing this issue with the old GUI (that we're using in data.geoscience.fr/nc/ for example). I hope this is handled in the new GUI when the Internationalisation is integrated.

And yes, it would better if we can have an interactive control on the language too.

[afeliachi]

Sorry for my last comment, I lost most of it.

We meant by "see all" to have the possibility i the GUI to see the registers content in all the possible languages. The UI templates language is not concerned y this.

So If I can resume, the solution is to do some language negotiation by default to show both the templates and the vocabulary content in the negotiated language, and we want also the possibility to interactively select the language (as it is the case in most multilingual websites).

The "see all" option would be applicable on the content, exactly the way you are explaining it here (for the latest release), to show the content in all possible languages. We are aware that this option is applicable only for register content, thus it could be separated from the overall language selection.

Sorry if am not clear enough, tell me if you need more details.

[afeliachi]

@der Thank you for the provided dev and wiki preview.
After few tests here are some feedbacks
The new devs & gui custumization in https://github.com/UKGovLD/registry-config-base/tree/1-translatable-ui seems generally to work perfectly. I tested the configuration by adding the language register and adding a fr.properties file (as a copy from en.properties). By translating some example labels in french, the GUI takes that into account correctly(green frames in figure 1 & 2) . The content negotiation also works perfectly for the vocabs content (blue frames in figures 1 & 2)

However we noticed some anomalies :
1- There seems to be a problem with special (accentuated) characters (red frames in figures 1 & 2). This problem occurs only with template labels and not with vocabs content
2- The detailed description of entities is not rendered at all (yellow frame in figure 2)

figure1

figure2

Do these issue seem minor for you? can they be corrected quickly?
Thank you

[simonoakesepimorphics]

@afeliachi At first glance I'm not able to replicate these issues. Please could you send your app.conf and translation file so I can investigate further?

There is a stray "~" next to the definition heading which I've fixed on the branch.

[afeliachi]

just recompiled the registry core from the 1-translatable-ui branch and still having the "~" and the missing detailed description problem. Am I missing something?

this is the language file I added (without the .txt extension of course, I added so I can upload it here). It is utf-8 encoded. It's the same as the en.properties file with some label only changed.
fr.properties

Thank you

[simonoakesepimorphics]

Thanks Abdel. You will also need to pull the latest changes from the 1-translatable-ui branch of registry-config-base to fix the "~". It's possible that the latest changes may also fix your other issues.

I haven't been able to replicate the encoding problem using the translation file provided. The text in your screenshot looks like it's the result of the é character not being correctly UTF-encoded, although in the file you sent it is encoded and renders correctly for me. It might be worth checking that this is the case in your test registry config.

I'm also not sure why the item description is not being rendered for you, as it looks correct for me. Are you getting any error / warning logs from the registry when you load the page? Having a copy of your app.conf file would be a help with debugging this.

[afeliachi]

I pulled the lastest changes thanks. That resolved both the "~" problem and the description rendering parts. Just to be sure.

however the accentuated characters problem persists. My language config file is well UTF-encoded in my test registry. Any ideas?

[simonoakesepimorphics]

It could be related to Java version or browser - Java 8 is recommended and I have tested in Chrome and Firefox. If that doesn't work then could you send me a TAR of your registry deployment directory (usually /opt/ldregistry) so that I can fully replicate the conditions?

[simonoakesepimorphics]

I've just pushed a change to the registry branch which adds the charset to the Content-Type header - previously was just relying on the meta tag in the document. Not sure if this will make a difference but worth a try.

[afeliachi]

Thanks for the addition but It didn't work.
My java version is actually 8. I can add that am testing it on windows
here is the content of the deployment directory
ldregistry.zip
Thanks

[simonoakesepimorphics]

I've been able to replicate the character encoding problem on a Windows machine - it arises when the file encoding property on the JVM (-Dfile.encoding) differs from the encoding of the properties file. On Windows, the JVM file encoding is Windows 1252 by default (whereas on my Mac it's UTF-8). So the solution would seem to be to make sure that the file itself and the file encoding property agree (changing either of them fixes the problem). I hope this approach is sufficient for your tool chain and deployment.

[simonoakesepimorphics]

After consulting with Dave, we've decided to change approach and require the properties files to be written as UTF-8. They will always be read as UTF-8 regardless of the system / JVM the registry is running on. So with this change (latest commit), your original properties file should work correctly.

[afeliachi]

@simonoakesepimorphics thank you very much.
Works like a charm now. thank you very much