Skip to content
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.

Better support for non-english/multi-lang areas #1643

Closed
openstreetmap-trac opened this issue Jul 23, 2021 · 5 comments
Closed

Better support for non-english/multi-lang areas #1643

openstreetmap-trac opened this issue Jul 23, 2021 · 5 comments
Assignees
@openstreetmap-trac
Labels
Component: osmarender Priority: major Resolution: wontfix Type: enhancement

Comments

@openstreetmap-trac
Copy link

Reporter: tal.bav[at]gmail.com
[Submitted to the original trac issue database at 2.44pm, Monday, 9th March 2009]

I request two features.

Feature 1: Add a "preferedLanguages" parameter which lists (most desired first, least desired last) the languages to use when using text tags (such as "name").

example:

assume preferedLanguages=":en,:de,,:he"

when osmarenderer need a "name" tag, it will use the first available tag of the following:

```name:en,name:de,name,name:he```

Feature 2: Support making one tag be exactly the same as another tag using the following construct:

  name:he="hebrew text"
  name="$(name:he)"

Note, no need to support name="123 $(name:he) 456". Just allow one tag to have the value of another.

The purpose of feature 1, is better and easier rendering of maps with custom languages.

The purpose of feature 2, is not to repeat the same name twice in areas that always use name:xx in addition to the name tag. For example, currently in Israel we use at least "name:he","name:en" and "name". And generally, "name"="name:he". The main reason we need a "name" tag at all, is the Slippy Map on the main OSM site.
@openstreetmap-trac openstreetmap-trac self-assigned this Jul 23, 2021
@openstreetmap-trac
Copy link
Author

Author: tal.bav[at]gmail.com
[Added to the original trac issue at 12.00pm, Wednesday, 11th March 2009]

More info about attachment:"ticket-1643-multilang.patch"

For each rule that displays text (text,areaText,caption,pathText), the key name of the text tag to be displayed is given in a "k" attribute.
For example:

<pathText k="name" dy="2px" class="piste-downhill-name" text-anchor="middle" startOffset="75%"/>

In this example k="name".
Now when osmarender wants to retrive the value of the "name" attribute for a specific way/node, it will:

  1. Get an initial value from by using preferedLanguages as described in the bug description for Feature 1.
  2. While the value from the previous step is "$(xxx)":
    get the value of key "xxx" (ignoring preferedLanguages), and goto step 2.
    (after 10 times, give up and return an error string, to avoid stack overflow)

@openstreetmap-trac
Copy link
Author

Author: randomjunk
[Added to the original trac issue at 2.58pm, Wednesday, 11th March 2009]

Please ignore Feature 2.

It's completely backwards incompatible for any renderer/user that doesn't support it (there are a lot by the way) and unnecessary. See mailing list thread on this subject for some other ways to achieve the requirements.

@openstreetmap-trac
Copy link
Author

Author: bob[at]cakebox.net
[Added to the original trac issue at 6.39pm, Saturday, 14th March 2009]

Replying to [comment:2 randomjunk]:

Please ignore Feature 2.

It's completely backwards incompatible for any renderer/user that doesn't support it (there are a lot by the way) and unnecessary. See mailing list thread on this subject for some other ways to achieve the requirements.

I completely agree.

I've attached a patch modified to not have the expansion feature (and also omitted some whitespace changes and other junk).

PS: it seems trac doesn't like the diff, there are changes to two files in there.

@openstreetmap-trac
Copy link
Author

Author: tal.bav[at]gmail.com
[Added to the original trac issue at 9.41pm, Saturday, 14th March 2009]

Replying to [comment:3 bob[at]cakebox.net]:

Replying to [comment:2 randomjunk]:

Please ignore Feature 2.

It's completely backwards incompatible for any renderer/user that doesn't support it (there are a lot by the way) and unnecessary. See mailing list thread on this subject for some other ways to achieve the requirements.

I completely agree.

I do not agree :)
However, I agree to remove Feature 2 from this patch and to further discuss it on the talk mailing list. Maybe we can all agree upon something.

@openstreetmap-trac
Copy link
Author

Author: iandees
[Added to the original trac issue at 9.02pm, Monday, 9th September 2013]

Cleaning aging tickets.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@openstreetmap-trac openstreetmap-trac

Labels
Component: osmarender Priority: major Resolution: wontfix Type: enhancement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@openstreetmap-trac