[editor] Use name in local language #6257
Labels
No labels
Accessibility
Accessibility
Address
Address
Android
Android
Android Auto
Android Auto
Android Automotive (AAOS)
Android Automotive (AAOS)
API
API
AppGallery
AppGallery
AppStore
AppStore
Battery and Performance
Battery and Performance
Blocker
Blocker
Bookmarks and Tracks
Bookmarks and Tracks
Borders
Borders
Bug
Bug
Build
Build
CarPlay
CarPlay
Classificator
Classificator
Community
Community
Core
Core
CrashReports
CrashReports
Cycling
Cycling
Desktop
Desktop
DevEx
DevEx
DevOps
DevOps
dev_sandbox
dev_sandbox
Directions
Directions
Documentation
Documentation
Downloader
Downloader
Drape
Drape
Driving
Driving
Duplicate
Duplicate
Editor
Editor
Elevation
Elevation
Enhancement
Enhancement
Epic
Epic
External Map Datasets
External Map Datasets
F-Droid
F-Droid
Fonts
Fonts
Frequently User Reported
Frequently User Reported
Fund
Fund
Generator
Generator
Good first issue
Good first issue
Google Play
Google Play
GPS
GPS
GSoC
GSoC
iCloud
iCloud
Icons
Icons
iOS
iOS
Legal
Legal
Linux Desktop
Linux Desktop
Linux packaging
Linux packaging
Linux Phone
Linux Phone
Mac OS
Mac OS
Map Data
Map Data
Metro
Metro
Navigation
Navigation
Need Feedback
Need Feedback
Night Mode
Night Mode
NLnet 2024-06-281
NLnet 2024-06-281
No Feature Parity
No Feature Parity
Opening Hours
Opening Hours
Outdoors
Outdoors
POI Info
POI Info
Privacy
Privacy
Public Transport
Public Transport
Raw Idea
Raw Idea
Refactoring
Refactoring
Regional
Regional
Regression
Regression
Releases
Releases
RoboTest
RoboTest
Route Planning
Route Planning
Routing
Routing
Ruler
Ruler
Search
Search
Security
Security
Styles
Styles
Tests
Tests
Track Recording
Track Recording
Translations
Translations
TTS
TTS
UI
UI
UX
UX
Walk Navigation
Walk Navigation
Watches
Watches
Web
Web
Wikipedia
Wikipedia
Windows
Windows
Won't fix
Won't fix
World Map
World Map
No milestone
No project
No assignees
3 participants
Due date
No due date set.
Dependencies
No dependencies set.
Reference: organicmaps/organicmaps-tmp#6257
Loading…
Add table
Reference in a new issue
No description provided.
Delete branch "name"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
❗ Helb for ios needed
I don't have a mac nor an iphone, so I can't implement the ios part. I tried to make changes without Xcode, but that didn't work without a proper IDE.
That's why I need someone who can mirror the changes done on Android to ios. Moreover the layout of the editing page needs to be change to have enough room for the "As it is written in the local language" string.
[editor] Use name in local language
As we can see in #762, #1478, #1481, #3378, #442 and other issues, OM has problems with handeling name tags. This is not a small bug but a fundametal problem with the approach OM uses. Hiding the default
name=*
from the users and then trying to do conversions that are assumed to be save leads to unpredictable behaviour and breaks osm data.I think it's best to not do any conversions in the editor but just present the actual osm data to the users. Just having one name field (for most features) will also make the editing UX simpler. At the moment many people get confused by the two name fields and use them for short-name and long-name or invent translations where there are none (e.g. most Restaurants don't have multilingual names and adding e.g.
name:en
doesn't really make sense) (Source: changeset observation)This PR consists of two changes.
Firstly it changes the languages that are shown to the user by default. Previously english, the user's language and the countrie's language the POI is in was shown. Now only
name=*
/Native for each country
/ "As it is written in the local language" is shown.Moreover, name conversions for displaying and saving names, that caused problems are removed. Previously OM would e.g. display the
name
value inname:en
in casename:en
is empty.Todo
Examples
Most OSM features just have a
name
tag. For these places OM previously used to convert thename
Tag and display it as german and english (note that the english name is totally made up by OM here). When saving, name changes are not forwarded to 'name' but to 'name:de' or 'name:en' while the outdated 'name' value stays in the OSM database. An example for this feature type is (https://www.openstreetmap.org/way/308082258)For features with several languages the picture is similar. The englisch value that shows up in the latest release is made up by OM as well. (https://www.openstreetmap.org/relation/147095)
Creating new features looks like this
Let's try to avoid mapsme mistakes and do it better by educating users. I'm counting on someone monitoring OSM edits to better understand if wrong names can be prevented at the OM side by improving the UI/UX.
Consider remove the code that won't be used later instead of commenting it.
Is this needed?
Here is the bunch of translations generated with
tools/python/translate.py
where the first part "the name of the place" should be removed, to get a correct hint. Note that the final phrase should look good taking into account the title "Name of the place".@ -28,3 +27,3 @@
StringUtf8Multilang::kDefaultCode == langCode)
if (StringUtf8Multilang::kUnsupportedLanguageCode == langCode)
{
return false;
Why kDefaultCode was removed here?
Please remove the code instead of leaving it in that state.
Should it be removed?
Is this variable needed?
Isn't the default name extracted in the loop below?
Is it needed?
Consider removing addFakes
Let's remove all related code, as the advanced mode is always used now.
Is this function/test still needed?
That doesn't look like the right way to write tests after changing the functionality.
Is there some way to keep the correct capitalisation in the
translate.py
tool?"de = Der name des ortes, wie er in der landessprache geschrieben wird" is actually
"de = Der Name des Ortes, wie er in der Landessprache geschrieben wird"
I will do that later, because it would brake the ios version if I did it now
No, result.mandatoryNamesCount is already 0. I removed it.
Removed the variable and only kept getter and setter dummies to not break ios
Yes, that bug was already fixed in
translate.py
:@ -15306,0 +15323,4 @@
fa = همانطور که به زبان محلی نوشته شده است
fi = Paikallisella kielellä kirjoitettuna
fr = Comme c'est écrit dans la langue locale
he = כפי שנכתב בשפה המקומית
nl is OK. (Sidenote: OM displayed the 'Sacré-Cœur' in Paris in my local language and I was confused for a moment)
Please test both iOS and Android implementations if they work properly. The debug version still uses the dev OSM server, right?
Any screenshots/videos from Android version on how it looks now?
@ -15306,0 +15310,4 @@
af = Soos dit in die plaaslike taal geskryf is
ar = كما هو مكتوب باللغة المحلية
az = Yerli dildə yazıldığı kimi
be = На мясцовай мове
Maybe just "In the local language"?
@ -15306,0 +15314,4 @@
bg = Както е написано на местния език
ca = Com està escrit en la llengua local
cs = Jak je napsáno v místním jazyce
da = Som det står skrevet på det lokale sprog
На мясцовай мове
@ -15306,0 +15319,4 @@
el = Όπως είναι γραμμένο στην τοπική γλώσσα
es = Como está escrito en la lengua local
et = Nagu on kirjutatud kohalikus keeles
eu = Bertako hizkuntzan idatzita dagoenez
Should it be
de = Wie in der Landessprache geschrieben
?@ -15306,0 +15342,4 @@
sv = Som det står skrivet på det lokala språket
sw = Kama ilivyoandikwa katika lugha ya kienyeji
th = ตามที่เขียนเป็นภาษาท้องถิ่น
tr = Yerel dilde yazıldığı gibi
На местном языке
@ -15306,1 +15348,4 @@
zh-Hans = 当地语言写道
zh-Hant = 因為它是用當地語言寫的
[editor_edit_place_category_title]
Місцевою мовою
Can needFakes parameter be removed?
Please check if indentation is 2 spaces everywhere.
@kirylkaveryn can you please help to remove this parameter? Or was it already removed?
nit: use single line instead of two lines, then tests will be more readable (more lines will fit the screen).
@ -291,4 +282,4 @@
{
vector<int8_t> nativeMwmLanguages = {GetLangCode("de"), GetLangCode("fr")};
auto const namesDataSource = EditableMapObject::GetNamesDataSource(
Was this order lost? Why is it not important?
Formatting looks inconsistent here.
@ -15306,0 +15310,4 @@
af = Soos dit in die plaaslike taal geskryf is
ar = كما هو مكتوب باللغة المحلية
az = Yerli dildə yazıldığı kimi
be = На мясцовай мове
this is also a valid option in "es".
I didn't remove this parameter. Why it should be removed?
Because it is not used anymore and completely removed from Android code. All related unused code should also be removed for iOS (when
addFakes == true
).@ -15306,0 +15319,4 @@
el = Όπως είναι γραμμένο στην τοπική γλώσσα
es = Como está escrito en la lengua local
et = Nagu on kirjutatud kohalikus keeles
eu = Bertako hizkuntzan idatzita dagoenez
I switched to "lokalen Sprache", because this is clearer for countries with different languages in different parts of the country (e.g. Belgium) (see: organicmaps/organicmaps#6257 (comment))
@ -291,4 +282,4 @@
{
vector<int8_t> nativeMwmLanguages = {GetLangCode("de"), GetLangCode("fr")};
auto const namesDataSource = EditableMapObject::GetNamesDataSource(
The functionality changed and now only 'default_name' is always shown. This simplified the code and we now need fewer tests.
PT = PT-BR
@kirylkaveryn The value of
needFakes
is ignored in the core, and you can also call the function with out a parameter. So you can safely remove allneedFakes
related code from iOS@ -15306,0 +15310,4 @@
af = Soos dit in die plaaslike taal geskryf is
ar = كما هو مكتوب باللغة المحلية
az = Yerli dildə yazıldığı kimi
be = На мясцовай мове
I still prefer "As it is written...", because it gives people the hint that they should just write down what's on the sign of the shop. But I don't have a strong opinion on this, so we can change it if you prefer "In the local language"
The value of
needFakes
is ignored in the core, and you can also call the function with out a parameter. So you can safely remove allneedFakes
related code from iOS@ -291,4 +282,4 @@
{
vector<int8_t> nativeMwmLanguages = {GetLangCode("de"), GetLangCode("fr")};
auto const namesDataSource = EditableMapObject::GetNamesDataSource(
If the country/region's languages are known, would it be more beneficial to also duplicate the default name into the tagged one, and encourage to add translations for those users who care? E.g. for Switzerland, when adding an object, I now see:
The last two in this case are less important and can be hidden by default (or left as is).
If I type German, then the name can be saved as name= and name:de=, right? (If fr, it, de are all changed, then there should be the sorted hard-coded order of languages per region, and the first one should be used as a name=).
By showing only "Name in local language" we can not be 100% sure which language was used to type it, right? And are losing the opportunity to save the name under an explicitly defined language.
That is true for adding new features on the map. For editing, we have different cases:
What would be more beneficial for OSM and users all over the world in the long term?
CC @Zverik
@map-per Fixed!
You can pick up the fix from my last commit here: organicmaps/organicmaps#7946/commits/aee10205fe6db5f7d29ca9a9c8a8d82922f5f48c
So you can safely remove the
needFakes
form cpp now.@ -291,4 +282,4 @@
{
vector<int8_t> nativeMwmLanguages = {GetLangCode("de"), GetLangCode("fr")};
auto const namesDataSource = EditableMapObject::GetNamesDataSource(
The problem with displaying multilingual names too prominent ist that, at the moment, many people get confused by the two (or more) name fields and use them for short-name and long-name or invent translations where there are none (e.g. most Restaurants don't have multilingual names and adding e.g. name:en doesn't really make sense)
That's why this PR simplifies the UX to display just one name field by default.
The problem with name conversions is that it it only takes regions with only one language into account. So the idea doesn't work any more if there are two languages, like e.g. in Belgium. And keep in mind that the OM implementation of this idea never worked properly, resulting in wrong and nonsense data being uploaded to OSM.
That's why this PR removes name conversions.
So in the long term it ist most beneficial to fix the bugs of the OM editor. Then no wrong data is uploaded to OSM and users all over the world get higher quality map data.
@ -291,4 +282,4 @@
{
vector<int8_t> nativeMwmLanguages = {GetLangCode("de"), GetLangCode("fr")};
auto const namesDataSource = EditableMapObject::GetNamesDataSource(
I agree that wrong data should not be uploaded to OSM. But is it the best way to fix that issue? The proposed approach is clear to every OSMer, but is it clear for inexperienced users?
One of the current issues is that users don't read that the name field says "French", or "Dutch", and write there some unrelated stuff. Will they read and understand "As in the local language"? It's even more confusing than "French" or "Dutch".
If confusion comes from many fields, what about displaying only relevant map languages then? Isn't it important to understand which language was used by a user when the name was typed? Especially in 2+ official local languages (Belgium, Switzerland, Canada, etc.)?
@ -291,4 +282,4 @@
{
vector<int8_t> nativeMwmLanguages = {GetLangCode("de"), GetLangCode("fr")};
auto const namesDataSource = EditableMapObject::GetNamesDataSource(
@map-per perhaps we could notify the user about what is "local language" is? Because in the current implementation, this may not be clear. So if I'm not a native speaker or just a tourist and cannot provide "name in local language" it would be better to skip this field? Because OM isn't for only experienced osmers, but for a wide range of users. What do you think?
@ -291,4 +282,4 @@
{
vector<int8_t> nativeMwmLanguages = {GetLangCode("de"), GetLangCode("fr")};
auto const namesDataSource = EditableMapObject::GetNamesDataSource(
I have not noticed any such errors while reviewing OM edits. Are you sure they exist?
No, that's not important in the OSM tagging scheme. That's just the way OSM is, we can't change that.
I think "As it is written in the local language" is clear enough
@ -291,4 +282,4 @@
{
vector<int8_t> nativeMwmLanguages = {GetLangCode("de"), GetLangCode("fr")};
auto const namesDataSource = EditableMapObject::GetNamesDataSource(
Didn't you explicitly mention that issue above? Or am I misunderstood you?
@ -291,4 +282,4 @@
{
vector<int8_t> nativeMwmLanguages = {GetLangCode("de"), GetLangCode("fr")};
auto const namesDataSource = EditableMapObject::GetNamesDataSource(
Ah, OK, then that's a misunderstanding. People invent translations, but they invent them in the right language.
@ -291,4 +282,4 @@
{
vector<int8_t> nativeMwmLanguages = {GetLangCode("de"), GetLangCode("fr")};
auto const namesDataSource = EditableMapObject::GetNamesDataSource(
Now that I think about it again, the short-name and long-name issues I saw are probably rather a result of the name conversion. So the users probably added a german name that was saved to name=* and then had second thought and changed the german name, but OM didn't change name=* but added name:de=*.
@ -15306,0 +15339,4 @@
ro = Așa cum este scris în limba locală
ru = На местном языке
sk = Tak, ako sa píše v miestnom jazyku
sv = Som det står skrivet på det lokala språket
Ok, let's test it in beta/production. Many thanks to @map-per for starting and finishing it, and for everyone else to support and improvements!
Please let me know at alex at organicmaps dot app if you want to receive regular master branch beta builds. I need to add your email to our Firebase group.
@map-per please let me know if you are interested in joining our closed Telegram/Matrix chat for active contributors.
Clean history, thanks!