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

250-change-language-fixes #275

Merged
merged 23 commits into from
Aug 14, 2023
Merged

250-change-language-fixes #275

merged 23 commits into from
Aug 14, 2023

Conversation

stefanschaller
Copy link
Collaborator

No description provided.

continue
}

val properties = "[\"coalesce\", [\"get\",\"name:$language\"],[\"get\",\"name:latin\"]]"
Copy link
Collaborator

Choose a reason for hiding this comment

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

Would we maybe also want to also coalesce to just "name" as an ultimate fallback here?

Copy link
Collaborator

@m0nac0 m0nac0 Aug 11, 2023

Choose a reason for hiding this comment

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

I haven't tested it, but I think otherwise non-latin-names might be completely missing from the map (if there is no latin transliteration for the name in the tiles)?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

name as final fallback sounds good in theory, but I'm not sure if something like that is working.

fun MapboxMap.setMapLanguage(language: String) {
val layers = this.style?.layers ?: emptyList()

val languageRegex = Regex("(name:[a-z]+)")
Copy link
Collaborator

Choose a reason for hiding this comment

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

I assume the idea here is to skip any layers with textfields that do not depend on the name from the tiles. But is also on purpose to ignore layers withtext = ["get", "name"]?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

We already ignore layers where ["get", "name"] is present, since the layer check for at least a : .

Copy link
Collaborator

Choose a reason for hiding this comment

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

Yeah, that's my question: is that on purpose?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Not saying it's right or wrong, just occurred to me that I'm not sure whether a developer would expect such a layer to be localized or not...

Copy link
Collaborator

Choose a reason for hiding this comment

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

Thinking about it more, i think there is a good argument for either approach:

  1. On the one hand, if the style author sets text = ["get", "name"] they may explicitly always want to show the non-translated name here --> we should ignore these layers
  2. On the other hand, if the developer explicitly calls this method to localize map labels, they might expect all map labels to be localized --> these layers should be localized as well

Copy link
Collaborator Author

@stefanschaller stefanschaller Aug 14, 2023

Choose a reason for hiding this comment

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

I would definitely go with option 1 because of multiple reasons:

  1. If the author just set ["get", "name"] or [ref], they want the plain name for sure.
  2. The developer should not care about which layer will be translated and which not, since the most developer are not familiar about the different layers and how the styling is working in detail.
  3. The setMapLanguage function would not work in our case, since we have a lot of usages of ["get", "name"] and [ref], and the text is just empty in that cases.

@stefanschaller stefanschaller changed the title Draft: 250-change-language-fixes 250-change-language-fixes Aug 14, 2023
@stefanschaller stefanschaller marked this pull request as ready for review August 14, 2023 04:52
@@ -9,5 +9,5 @@ dependencies:
meta: ^1.0.5

environment:
sdk: '>=2.12.0 <3.0.0'
sdk: '>=2.14.0 <3.0.0'
Copy link
Collaborator

Choose a reason for hiding this comment

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

Strictly speaking, this is a breaking change, right? Since 2.14 is almost 2 years old I think its fine, but we might want to note it in the changelog.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Ah, maybe in general add an entry to the changelog about this PR

Copy link
Collaborator

Choose a reason for hiding this comment

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

Sorry about all the nitpicks, just treat them as suggestions. I'm really happy about the work you guys are doing on this repo!

Copy link
Collaborator

Choose a reason for hiding this comment

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

We can add a notice to the readme, besides that the PR looks very good. 👍🏽

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@m0nac0 Nitpicking like that is definitely appreciated!

@m0nac0
Copy link
Collaborator

m0nac0 commented Aug 14, 2023

LGTM!

@stefanschaller stefanschaller merged commit c6055fd into main Aug 14, 2023
11 checks passed
@stefanschaller stefanschaller deleted the 250-change-language-fixes branch August 14, 2023 12:29
JanikoNaber pushed a commit to JanikoNaber/flutter-maplibre-gl that referenced this pull request Aug 23, 2023
Co-authored-by: Julian Bissekkou <julian.bissekkou@tapped.dev>
m0nac0 added a commit to m0nac0/fork-flutter-maplibre-gl that referenced this pull request Sep 25, 2023
m0nac0 added a commit to m0nac0/fork-flutter-maplibre-gl that referenced this pull request Nov 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants