Noticed the FacetCategory and FacetLabel remains in English and not toggling with language.
So, thought of adding those terms as key=value pairs in the bundle property files and implement as below in search-include-fragment.xhtml
https://github.com/IQSS/dataverse/blob/develop/src/main/webapp/search-include-fragment.xhtml#L177
modify to
Example:
FacetCategory:
_#search-include-fragment.xhtml bundle[facetCategory.friendlyName]_
Dataverse\u0020Category=Cat茅gorie Dataverse
Publication\u0020Date=Date de publication
Author-Name=Nom \u2014 Auteur
Subject=Sujet
Deposit\u0020Date=Date de d茅p么t
File\u0020Type=Type de fichier
File\u0020Tag=Libell茅 de fichier
Access=Acc猫s
Keyword-Term=Mot-cl茅 \u2014 Terme
Author\u0020Affiliation=Affiliation de l'auteur
Language=Langue
Kind\u0020of\u0020Data=Type de donn茅es
Publication\u0020Status=Statut de publication
FacetLabel:
Researcher=Chercheur
Research\u0020Project=Projet de recherche
Journal=Revue
Organizations\u0020or\u0020Institutions=Organisation ou 茅tablissement
Teaching\u0020Course=Cours
Uncategorized=Sans cat茅gorie
Research\u0020Group=Groupe de recherche
Laboratory=Laboratoire
Agricultural\u0020Sciences=Sciences de l'agriculture
Arts\u0020and\u0020Humanities=Arts et sciences humaines
Astronomy\u0020and\u0020Astrophysics=Astronomie et astrophysique
Business\u0020and\u0020Management=Affaires et gestion
Chemistry=Chimie
Earth\u0020and\u0020Environmental\u0020Sciences=Sciences de la terre et de l'environnement
Engineering=G茅nie
Medicine,\u0020Health\u0020and\u0020Life\u0020Sciences=M茅decine, sant茅 et sciences de la vie
Computer\u0020and\u0020Information\u0020Science=Informatique et science de l'information
Law=Droit
Mathematical\u0020Sciences=Sciences math茅matiques
Physics=Physique
Social\u0020Sciences=Sciences sociales
Other=Autre
Published=Published
Unpublished= Non publi茅e
Draft= Version provisoire
In\u2000Review= En r茅vision
Deaccessioned=Retir茅e
@scolapasta: please advice

Thanks
@4tikhonov mentioned the need to translate facets in last week's community call: https://groups.google.com/d/msg/dataverse-community/71kuJ6TdUIg/1NtdQPEcBAAJ
I had asked him to leave a comment on #4684 but now that this issue exists, we should have the conversation here instead.
hi @pdurbin and @JayanthyChengan, this is exactly what I have asked during Community call. We have already requested translation of SOLR schema to all languages from DataverseEU community members.
For facet categories, I would think it would be just straightforward to take what solr returns and use that as a key into a bundle file. Did that not work so straightforwardly?
For facet labels:
I think it's because these are "values" and we store in solr the values so they are searchable. (we don't translate free text fields, for example)
So not sure what is best here. we could store the "key" in solr and then translate that with the bundles? but not sure if it would be weird that some of the metadata is translated and some is not.
I think we need to decide what the behavior we want is, before we decide on how to do that.
The biggest problem is a maintenance of all properties in all languages in bundle file and solr. We're considering possibility to turn all properties to RDF that will be checked by some tool after every Dataverse update and will show all new/not translated properties with some provenance information who is responsible for the specific language.
@scolapasta
We would like to build the interface with the "facetCategory.friendlyName" and "facetLabel.name" in search-include-fragment.xhtml toggles along with the language selection.
As we implemented at https://dataverse.scholarsportal.info/ , where key=value pairs are added to bundle property files
@JayanthyChengan @juancorr there are two issues related to facets and internationalization, this one and #5623. I'd like to suggest we close one and have the discussion in one. (and arbitrarily chose this one, but am fine switching). Is that OK? (if we do we should connect the other PR to this one.)
That said, I have thoughts on both PRs. We had a meeting here (tech hours) where we discussed, and while I'm not yet sure what our final guidance might be, we have some thoughts.
Please add some discussion if we can figure out how to move forward. My suggestion is that we start with a variation of @juancorr's pr (modifying it to support facets from any metadata block) and we would get the facet categories first.
@JayanthyChengan @juancorr I went ahead and consolidated the issues - but feel free to let us know if you prefer it the other way around.
Could you please provide comments on my suggestion above?
@scolapasta : I am fine with continuing the discussion in this issue.
So, as a first step, I was looking only at translating the facet categories.
In the current code, the Facet Category related to any dataset field from metadata block is translated properly in the interface. here
for (DatasetFieldType datasetField : datasetFields) {
String solrFieldNameForDataset = datasetField.getSolrField().getNameFacetable();
**String friendlyName = datasetField.getDisplayName();**
if (solrFieldNameForDataset != null && facetField.getName().endsWith(datasetField.getTmpNullFieldTypeIdentifier())) {
// give it the non-friendly name so we remember to update the reference data script for datasets
facetCategory.setName(facetField.getName());
} else if (solrFieldNameForDataset != null && facetField.getName().equals(solrFieldNameForDataset)) {
if (friendlyName != null && !friendlyName.isEmpty()) {
**facetCategory.setFriendlyName(friendlyName);**
// stop examining available dataset fields. we found a match
break;
}
}
datasetfieldFriendlyNamesBySolrField.put(datasetField.getSolrField().getNameFacetable(), friendlyName);
}
But there are some facet fields added to the solrQuery https://github.com/scholarsportal/dataverse/blob/develop/src/main/java/edu/harvard/iq/dataverse/search/SearchServiceBean.java#L227 and I guess they are not specific to any metadata block.
Please check staticsearchfield at here
Can we add those to bundle.properties? Correct me if I am wrong.
@JayanthyChengan Yes, for the static ones, having them in the main bundle is fine.
Hi @JayanthyChengan and @scolapasta,
sorry for my late response. I am comfortable with the @JayanthyChengan solution. In e-cienciaDatos tests, we have put all solr entries in a new properties file (we have called it solr), but this solution have some problems:
You can see current e-cienciaDatos develop environment in http://oaimadrono.uned.es:8080/dataverse/madrono .
The code and properties file are:
@scolapasta , I think that the ":" solution to translate compound fields could not be valid for all languages. Another simple solution could be ignore the right part (Autor instead of Autor: n么m) .
@JayanthyChengan , I think that you are right. We have updated the block of code that you have signaled in the previous comment:
@scolapasta Please check the pull request https://github.com/IQSS/dataverse/pull/5697 ,where I tried both FacetCategoryName and FacetLabels to be translated from metadatablock property files and added staticSearchField in bundle.properties
The staticSearchField are coming from SearchFields.java, so added all those fields in Bundle.properties
Haven't handled compound names in facetCategory. Please review my code and let me know your opinion. Thanks
@scolapasta - is there any update on the PR #5697 ? Thanks
@scolapasta, @JayanthyChengan, @juancorr
Suggestion regarding compound names in facetCategory.
Why not use the > symbol which suggests a logical hierarchical sequence and that is often use with breadcrumb navigation. Would that work for all (a majority of maybe?) languages ?
e.g.:
Auteur > Nom
Auteur > Affiliation
Renseignements sur la subvention > Organisme subventionnaire
Renseignements sur la subvention > Num茅ro de la subvention
Author > Name
Author > Affiliation
Grant Information > Grant Agency
Grant Information > Grant Number
Autor > Nombre
Autor > Afiliaci贸n
Informaci贸n de la subvenci贸n > Agencia subvencionadora
Informaci贸n de la subvenci贸n > N煤mero de subvenci贸n
Hi @mhvezina, I closed this because it was marked as delivered in 4.16. If there's still specific work to be done, can you you create this in a new issue? Thank you for all of your work on internationalization !!
sorry about that @djbrooke. I have created a new issue: #6573
Should I delete the former comment made on the #5697 closed issue?
No need to delete it, and thanks for creating the new issue so quickly!