For your information,
an update has been added to the Place page regarding the language in which we write the primary names of places.
Isnโt the option of adding a place just because of language a bit excessive? The map is already full of dots in certain areas as it is.
Isnโt it better to stick with that?
Another option is to keep the main name in two languages, but add โKing David Hotelโ as an alternative name instead of having a dual main name.
The problem with adding an alternative name in a different language is that it only serves as a trigger for the search server to surface the place in search results, but the name displayed in the results is always the primary name.
Back then I had a thought for a dedicated script for this, one that would create several point places but cleanly associate them all with the primary place and take care of hiding the points for those using the script. And of course, it would sync the changes made to the primary place to all secondary places (phone, opening hours, etc.).
I abandoned the idea in the past because from the limited market research I did, I saw that this isnโt a common problem and the amount of work would outweigh the benefits, but Iโm willing to reconsider it.
Details of how the script works
Is a script for managing places in multiple languages required?
- Yes
- No
0
voters
This isnโt necessarily a problem but rather an advantage. Itโs all in the eye of the beholder. And specifically, this was the original intent.
Itโs an advantage when it comes to someone who speaks the language in which the place name is written. When itโs a place that serves drivers who speak different languages and you canโt include all of them in the primary name, then it doesnโt really serve everyone, because although they search in their own language, they only encounter results in other languages.
Now I understand the thing about the details. What happens when you choose a Google location thatโs linked to both places?
Ideally, there shouldnโt be a case where a place linked to Google appears in the app as a separate result. If it does, I think itโs random. When there were more places like this (with a separate entry for translation), I would only link the main one. Google has an option to translate within the place itself, so itโs not an issue because it appears in the userโs language in the search.
The issue is never clear-cut.
For example, if you get a result in the language you wanted but the businessโs signage is in the local language, it wonโt necessarily help you recognize that youโve reached the right place.
Regarding Google Places linked to more than one location, there are quite a few of these on our map. For various reasons. And sometimes to more than two locations. What is clear is that the result of such a linkโฆ is unclear.
While Google results do allow searching in multiple languages (via existing or automatic translation), the link sometimes causes the immediate result displayed to be the place the result was linked to, with its primary name.
In places intended for speakers of other languages, signage will usually appear in the relevant language. In any case, it is not relevant for languages that are not used very much in the country (for example, Italian). It is relevant in areas specifically intended for speakers of that language.
If there were such a script, I would probably install it. Given the number of places in two languages that I handle, my usage of such a script would likely be quite low.
I didnโt vote because I donโt have a definitive opinion on whether such a script is โrequired.โ
Edit: How do you think it would work?
โIf it places the locations on top of each other, it will make editing very difficult for those who donโt have the script, and if it places them side-by-side, the nearest segment might be different between the locations and the editor wouldnโt notice (unless there is always an entry point [in the same location for both of them]).
A script integrated with a bot.
The script will provide editors who use it with a simple and easy editing experience, where all information is concentrated in the main place and everything can be edited from it (in fact, editors who use the script wonโt see the other places at all).
When an editor creates a version in a different language for the main place, they will create a point place nearby, one for each language selected in the script (in addition to the main language). Their placement on the map is up to the community to decide. Generally speaking, they could be placed on top of each other, depending on the decisions made (if it is indeed decided to develop such a tool).
For those not using the script: they will see the additional places. However, editing them wonโt be necessary if it is decided to run a dedicated bot developed to โduplicateโ the changes from the main place to the secondary places.
This way, for any editor (or app user) who makes a change to the main place, the change will be automatically synchronized to all secondary places (referring to entry points, technical details like address, phone, website, opening hours, etc., and not items requiring translation).
Of course, if necessary, it could be made so that any change in the secondary places syncs to the main place.
And if needed, an option could be added to โdisconnectโ certain fields so they donโt sync; for example, if there is a dedicated phone line for speakers of a specific language and we created a dedicated place for them in that language, the phone in that place could be set not to sync with the phone updated in the main place.
In short, the skyโs the limit. But I donโt think thereโs a demand for such a script, at least not today.
Of course, ideally, this is a tool that should be developed by the company rather than the community.
Of course, this solution also has drawbacks and limitations, all of which can be discussed if such a development is decided upon.