Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fixes for language filtering to support private-use subtags #330

Merged
merged 1 commit into from Dec 8, 2022

Conversation

litvinovg
Copy link
Contributor

@litvinovg litvinovg commented Sep 26, 2022

What does this pull request do?

Fixes created list of tags for cases with private use sub-tags.
Example
For requested language fr-CA-x-uqam creates list of acceptable [ fr-CA-x-uqam, fr-CA , fr ]

How should this be tested?

Unit tests are included in this PR

Interested parties

@chenejac
@brianjlowe

Copy link
Contributor

@chenejac chenejac left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@litvinovg please check my comments before we merge your contribution

Comment on lines +31 to +41
String[] subtags = lang.split(SEPARATOR);
int length = subtags.length;
for (int i = 1; i < length; i++) {
int lastIndex = length - i;
if (PRIVATE_USE_SUBTAG.equals(subtags[lastIndex - 1])) {
continue;
}
String baseLang = String.join(SEPARATOR, Arrays.copyOfRange(subtags, 0, lastIndex));
if (!lang.equals(baseLang) && !this.contains(baseLang)) {
this.add(baseLang);
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe I need this code for this PR. However, I am wondering can we centralized working with languages/locales, at the moment we are struggling with acceptable languages and format of a language tag at a couple of places:

Copy link
Contributor

@chenejac chenejac Sep 27, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also, please notice that if we define this language tag in the runtime.properties
fr_CA_x_uqam
once when it is loaded in a Locale object, the code
locale.toLanguageTag().toString()
will produce
fr-CA-x-uqam
while the code
locale.toString()
will produce
fr_CA_#x-uqam
I believe this might introduce some issues, for instance here - https://github.com/vivo-project/Vitro/blob/9230bb3f23ffbfd58347ae61bb7ce55bd0d006d3/api/src/main/java/edu/cornell/mannlib/vitro/webapp/utils/searchengine/SearchQueryUtils.java#L211:L217

@brianjlowe
Copy link
Member

Added my approval. @chenejac is the directive not to merge from 27 Sep still valid or stale at this point?

@chenejac
Copy link
Contributor

chenejac commented Nov 4, 2022

Added my approval. @chenejac is the directive not to merge from 27 Sep still valid or stale at this point?

I would suggest to postpone merging of this PR. I am hoping we might have much wider picture and complete solution for usage of private tags in the next sprint.

@chenejac chenejac merged commit 81e12cc into vivo-project:main Dec 8, 2022
chenejac added a commit that referenced this pull request Dec 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants