Locale/Language site setting + "restrict values" on browse pages

[allanaaa]

When a site is set to, say, French, and the installation default is something else, and the "Filter values based on site locale" checkbox is checked, I would expect that the Browse Title and Browse Description fields used on the Browse pages would only display title and description values that match the FR language. That is, if there is no title or description in the right language, it would show nothing, or "[no title]" (in the right language) or something.

Instead, they display the language-matched values if available, but fall back on en-tagged values. (There are no non-tagged values.) It falls back on English even when the installation locale is set to, say, Italian, and there is an Italian value to choose instead.

I would expect these to be empty or throw up some kind of error if the checkbox is checked, if we're going to be really consistent. But maybe this should be a second setting.

Either way, it should probably fallback to the installation locale, not to English.

[zerocrates]

There's no "fall back to English" code. The rules for what happens are a little complex thanks to the forest of options related to these bits of display, but they are (or should be):

(all of these with a locale set for the site and "filter values" enabled)

• If you haven't selected a custom title property in the site settings:
  • it will prefer a value of the selected language for the property the resource's template defines as the title property (or dcterms:title if none is so defined);
  • if no language-matching value exists, it will use the resource's stored default title (in general, the first value of the title property)
• If you have selected a custom title property in the site settings, it will only use a matching-language value of that property

Rules for descriptions are basically the same.

[allanaaa]

Ah, the first value! Makes sense that this doesn't come up much. This is probably coincidentally working for most users that don't bother setting languages on their property values.

We just want to worry about people who are intentionally creating multilingual installations, like two sites in different languages with the same resources and design. In that case, this is very opaque.

I would think there are a lot more instances of people using multiple values for one field with language tags, and relatively few selecting different site browse properties for each language.

I'd make those forest-of-options behaviours the same, first off. "Filter values" says "Show only values matching the site language setting and values without locale ID" so that should always be true.

"Filter values" on a site should apply to everything all the time - browse, view, search results(, map markers, timelines....). For Browse, because we have the extra customization, it would work:

• If browse properties are set, look for the site browse title in the right language
• then look for a site browse title's value without a language tag
• If no browse property is set, then look for the resource template title in the right language
• then look for the resource template title without a language tag
• If no resource template, then look for dctitle in the right language, or no language.

At this point in the logic, "Filter values" would jump in and refuse to display anything else. If not:

• then look for the site browse title's first value
• then look for the resource template title's first value
• then whatever final fallback, first dctitle or something.

That's a lot. We should just have fewer user settings.

[zerocrates]

We've talked about getting rid of the site title/property settings because they've been basically obsoleted by the later-added resource template ones. It's just a matter of deciding when to bite the bullet on that. Getting rid of the site title/property settings would eliminate the situation where things behave differently, which would just leave the question of how they should behave. The logic for the title/description display code that works through the templates was basically that, we have something here we know is a title, so shouldn't we use it rather than saying there's no title.

What we have differs from what you suggest in a couple ways: maybe most importantly is that without filter values on we don't care at all about the language tags when doing titles and descriptions: you just always get what's first, and we'd probably want to keep it that way.

In up-to-date code used for browses, the match used when the feature is enabled is to an array of the user's selected locale and the empty string, so every check for "is this value the right language" is a check that the value's language is either the actual correct tagged language or that the value has no language tag: either is a match. This means there are fewer "steps" to deciding what to print, and also means that we don't prefer having the actual tag over being untagged: if you have two values, one is the matching tagged language and one is untagged, whichever is first will be what you get.

[zerocrates]

As for it seeming to work for people, my impression is that we have mostly users that just don't use the lang features at all, or do some tagging and don't use the value filter. Then we have another group who's heavily using tagging and basically tags everything and is using the value filter. When you tag everything and reliably have metadata in your chosen language for the site, you don't end up in any of these cases or spots of ambiguity really.