Opened 2 years ago
Last modified 15 months ago
#21963 new enhancement
Spelling of "center" and other words with differences in AE vs. BE
| Reported by: | skyper | Owned by: | Klumbumbus |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Internal preset | Version: | |
| Keywords: | spelling gui centre center | Cc: |
Description (last modified by )
In #21907, I noticed that we use BE instead of AE for e.g. "center".
We have en_GB (UK) for British spelling but as far as I know the default in JOSM is American English.
Is it ok to change to AE for the gui language or are there reasons for the use of mixed spelling?
Attachments (0)
Change History (13)
comment:1 by , 2 years ago
| Summary: | Spelling of "center" and other words with differences in AE and BE → Spelling of "center" and other words with differences in AE vs. BE |
|---|
comment:2 by , 2 years ago
comment:3 by , 2 years ago
| Description: | modified (diff) |
|---|
follow-up: 5 comment:4 by , 2 years ago
Sure, I planned to change centre to center together with #21907 and #21903.
Are there more words to look at?
comment:5 by , 2 years ago
Replying to skyper:
Are there more words to look at?
So far I found "Neighbourhood" and "Theatre" beside many "Centre".
comment:6 by , 2 years ago
| Owner: | changed from to |
|---|
comment:8 by , 16 months ago
| Milestone: | → 23.01 |
|---|
Using center in the presets is a bit more confusing because it is different from the actual osm tags, however it is more consistent as we have "English (United Kingdom)" as alternative language to the default English in JOSM (=AE), compare also ticket:8208#comment:11.
For Color/Colour we already use both in the presets (<combo key="colour" text="Color (HTML...).
So im sligthly in favor of changing centre to center.
comment:9 by , 16 months ago
| Owner: | changed from to |
|---|
comment:10 by , 16 months ago
JFYI: It seems on the OSM website they want to do it the other way around:
our en is really en-GB so if anything that calls for an en-US translation
(from https://github.com/openstreetmap/openstreetmap-website/issues/3671#issuecomment-1368032461)
Another related discussion for iD: https://github.com/openstreetmap/id-tagging-schema/issues/357
follow-up: 12 comment:11 by , 16 months ago
So changing to AE would throw away all translations of the following list. I'm not sure if it is worth it. Especially since the wiki uses BE in the description of the tags and we display BE in presets as well when raw tags are shown, e.g. in all the "Type" combo lists of all the sport presets (there are no extra display values defined).
It would be really helpful if one could specify in a commit to keep the translations.
- Dive centre
- Adult gaming centre
- Arts Centre
- Community Centre
- Recycling Centre
- Sports Centre
- Fitness Centre
- Garden Centre
- Administration centre
- Theatre
- Neighbourhood
strictly also from background imageries(?):
- 2020 Ortophotos, Centre part of Moldova, Scale 1:5000, 20cm, true colours, covers the center part of Moldova. [Moldova-map.md server]
- SSB City Centres overlay
- A presence/absence tree cover dataset is derived from SPOT Panchromatic imagery (10m pixels) by a combination of digital classification and visual interpretation . The presence/absence dataset is then grouped into three density classes (Dense, Medium, Scattered) by neighbourhood and proximity cell based analysis. The raster dataset is converted to vector as a final step. Tree cover is defined as woody vegetation greater than 2 metres in height and with a crown cover (foliar density) greater than 10 percent.
and from Plugins:
- Analyse a set of GPS points to obtain its centre and direction of spread.
- select gpx points and "blam!", find centre and direction of spread
- Split by neighbourhood
- Split this data by neighbourhood (admin_level=11).
<html> <div style="font-family:sans-serif"> <ul> <li><b>Select the to be aligned segment.</b> You can do this by simply <b><i><span style="color:green">click</span></i></b>ing on a different segment. The rotation pivot will be highlighted by default in the centre of the segment. </li> </ul> </div> </html>
<html> <div style="font-family:sans-serif"> <ul> <li><b>Den auszurichtenden Abschnitt auswählen.</b> Dies ist einfach durch <b><i><span style="color:green">Klick</span></i></b>en auf einen anderen Abschnitt möglich. Der Drehpunkt (standardmäßig im Abschnittszentrum) wird hervorgehoben. </li> </ul> </div> </html>
<html> <div style="font-family:sans-serif"> <ul> <li>Optionally <b>change the rotation pivot point</b>. In order to get parallel with the reference segment, the to be aligned segment will rotate around this point. You can choose the two extremities or the centre of the segment by <b><i><span style="color:green">click</span></i></b>ing nearby. </li> </ul> </div> </html>
comment:12 by , 16 months ago
Replying to Klumbumbus:
It would be really helpful if one could specify in a commit to keep the translations.
It would be, but I don't think we can. While PO files do have fuzzy entries, I don't think our current workflows will actually mark entries as fuzzy -- I believe we literally throw away the current translations, and copy the new translations in (I think we effectively do a cp new.po old.po).
In order to have fuzzy entries, we would need to extract the new translations to a different folder, and then run something like msgmerge --output merged.po --update original.po reference.pot --compendium=new.po (I think that will work, but I'm haven't tried it).
Really, we'd probably want to add a target to the i18n build.xml like updateFuzzy, or add an empty file to source:trunk/resources/data like .requiresFuzzyI18n, and then have an if in the i18n build.xml. I'm not a fan of having an empty file come in and out of existence though. So then we'd have to do something like:
current_revision=$(svn info | grep 'Last Changed Rev' | awk -F':' '{print $2}') # Get the revisions where translations could have been modified for revision in $(svn log resources/data --quiet | grep 'r' | awk '{print $1}'); do # Check to see if the translations were modified if [[ $(svn diff --change $revision --summarize | grep 'resources/.*.lang' | wc -l) -gt 0 ]]; then # Look to see if there might be slight changes to translations since the last update. if [[ $(svn log --limit $((current_revision - ${revision#r})) | grep -i 'fuzzy translation') -gt 0 ]]; then # Do msgmerge stuff here break # Don't go past the last i18n update fi fi done
That should really be generified for plugin use, but core translations are a bit more important.
comment:13 by , 15 months ago
| Milestone: | 23.01 |
|---|
Milestone removed. Too much loss for too less benefit.
I'm OK with this. But we'll probably want to do it after we release 22.03, just to give translators some time. Unless we are able to set the current translations as equivalent anyway. I really haven't played around with our translation system, so I don't know how well it deals with minor changes to text (i.e., do translators have to retranslate a whole string when a typo is fixed?) I would hope that it sets the current translation as "fuzzy", but I don't know.