VIVO-1451 Capability Map i18n #67
Conversation
feeded from vivo.all.properties Conflicts: webapp/src/main/webapp/js/visualization/capabilitymap/graph_new.js webapp/src/main/webapp/templates/freemarker/visualization/capabilitymap/capabilityMap.ftl
|
Glad to see these hard coded language strings teased out. The way VIVO is distributed now vivo-languages is not included by default and english i18n strings are used from the VIVO project itself. Not sure if that's the way it should be... but this pull request reverses that which I think is outside the scope of the ticket and PR. Side note, are you using an IDE that is applying styling to the code automatically? All the white space, indentation, and line break changes make evaluating the actual changes a lot more difficult. It would be a lot easier to review if all the styling changes were reversed. |
|
The whitespaces might be from me.
I usually put some interline space in order to have a easier read.
I'll try to clean them on merge next time. Sorry for the inconvenience
Getting the strings out the code was necessary for this PR in order to have
the feature interface able to change entirely when user
switches language.
I followed what exists already in the app and what I proposed in the last
PR. If it should not be done this way then we need to talk about
it cause we are about to implement this approach on the whole application.
…On 2 May 2018 at 12:20, Ben ***@***.***> wrote:
Glad to see these hard coded language strings teased out.
The way VIVO is distributed now vivo-languages is not included by default
and english i18n strings are used from the VIVO project itself. Not sure if
that's the way it should be... but this pull request reverses that which I
think is outside the scope of the ticket and PR.
Side note, are you using an IDE that is applying styling to the code
automatically? All the white space, indentation, and line break changes
make evaluating the actual changes a lot more difficult. It would be a lot
easier to review if all the styling changes were reversed.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#67 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AafIrvYXI_VVN679kTbn06dnYEj6YfWXks5tudzJgaJpZM4TvmA->
.
--
Kitio Fofack, PMP
CEO ARETEX S.E.N.C.
|
|
I believe this is the correct approach and it is very much needed. Switching from hard-coded english terms to i18n tags is a no-brainer, we definitely should merge those changes. I'm just not sure if changing the inclusion of the vivo-languages dependencies from opt-in to opt-out is appropriate for this Jira issue and pull request. I'm referring to the removal of the comment lines here, here, etc. |
|
This issue has been added at the begining of the sprint as we were almost
done.
The issue(modifiying the built process in order to get a multi-lingual VIVO
that will no more require copying manually files) could have been treated
seperately, I agree with you.
But as we were working on CApability Map i18n, solving that issue seemed
important and somehow related
since we want the feature able to work in a new language right after the
next build of the VIVO following
the build of VIVO-Language.
…On 2 May 2018 at 17:09, Ben ***@***.***> wrote:
I believe this is the correct approach and it is very much needed.
Switching from hard-coded english terms to i18n tags is a no-brainer, we
definitely should merge those changes. I'm just not sure if changing the
inclusion of the vivo-languages dependencies from opt-in to opt-out is
appropriate for this Jira issue and pull request. I'm referring to the
removal of the comment lines here
<https://github.com/vivo-project/VIVO/pull/67/files#diff-d90f49b78bca425e67e44af54c56207eL111>,
here
<https://github.com/vivo-project/VIVO/pull/67/files#diff-fc03af4b731a53dfe9dbaec754d61b87L48>,
etc.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#67 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AafIrrZflh7UiYGh4kM9dOQzQGYbcamjks5tuiCJgaJpZM4TvmA->
.
--
Kitio Fofack, PMP
CEO ARETEX S.E.N.C.
|
|
With Kitio's help I was finally able to build with multilanguage support. In summary, clone vivo-languages repo w/ Kitio's PR, mvn install from inside vivo-lanauges. Add to runtime.properties Issues I see on first glance:
|
|
@gneissone I fixed the issue on Reset button. |
|
I agree that all labels should have a language tag, but I disagree that the capability map should ignore those that don't. Concepts in OpenVIVO don't have language tags. If we upgraded OpenVIVO following the current upgrade procedure the Capability Map would return zero results. The perception will be that upgrading breaks the Capability Map. I checked some concepts at Scholars@Duke, CU Experts, and Connect UNAVCO and none of the sites have language tags on their concept labels. One of the following three should happen:
|
|
See https://wiki.duraspace.org/display/VIVODOC110x/Data+types+for+string+and+language recommendation 3. Applies to labels for concepts. |
What about a scientific concept like Drosophila melanogaster? Following recommendation 3 there should be no language tag and therefore it would never appear in the capability map. |
|
Agree, the capability map should render strings without language tags. But in your specific example, perhaps the language tag is latin. @LA (latin) or a language tag for binomial nomenclature if there is one. |
|
Sure, you could add the latin tag. In reference to this pull request, that highlights another situation where the capability map should display a concept in a language other than the one currently selected by the user. In my opinion the capability map should include all concepts (as it currently does), even if there isn't a label in the current language.
I would say in that order of preference, but maybe no tag should have higher priority than the english tag. This conversation is relevant to the rest of the app, too. Right now, if a label isn't available in the selected language it picks the first one returned. So you get a mashup of many languages. |
|
I believe there are standards for internationalization that describe processing very similar to what you are describing. We should find them and align internationalization work with accepted best practices. |
|
I'm coming late to this conversation, so forgive me if this is irrelevant, but... It sounds like you might want to change the code to use a Language-Aware data model, such as a This should be accessible by a call like In other words, it might be possible (perhaps even easy), to allow the concept map code to delegate this issue to the RDFService. Again, I apologize if this is not useful, or has already been considered. |
|
@j2blake your input is very usefull ! |
|
Great. If I can answer any questions, let me know. |
|
Reopening this pull request. In an effort to follow current best practices, the VIVO project will now be developed against the |
|
I believe this PR has been replaced with #84 |
Also see https://jira.lyrasis.org/browse/VIVO-1892 / #179. |
Move files from everytime to firsttime
This PR makes the Capability Map fully internationalized.
JIRA Issue: https://jira.duraspace.org/browse/VIVO-1451
What does this pull request do?
After integrating this PR, one will be able to display the feature in different languages and then run the feature in the current language selected.
What's new?
Text from template are replaced by reference to values in language properties files.
Text in Javascrpt are replace by variables containing values from language properties files.
The SPARQL queries are language aware and retrieve only the data having the proper language tag
How should this be tested?
This new feature should be tested using a multilingual sample dataset, here are the steps:
1- Build VIVO languages updated on this PR: vivo-project/VIVO-languages#9
2- Build VIVO and enable fr-ca in runtime.properties
3-import sample data n3 dataset in VIVO (The corresponding PR creates transaltions for fr-CA: vivo-project/VIVO-languages#9)
4-Select English Language and run search then Search and expand
5-Only English terms should appear among research areas and on the resulting graph
4-Select another language (fr-ca)
6-You should be redirected on the capability map context but cleared
7-All the interface should appear in the selected language
8-Search then "search and expand"
9-Research areas in the search bar and result apprearing should all be in fr-CA
Additional Notes:
This PR is comming along with PRs on VIVO-languages(vivo-project/VIVO-languages#9) and;
VIVO-sampledata (vivo-project/sample-data#2) and require them.
Interested parties
@awoods @gneissone