Opened 18 months ago

Last modified 8 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 skyper)

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 Changed 18 months ago by skyper

Summary: Spelling of "center" and other words with differences in AE and BESpelling of "center" and other words with differences in AE vs. BE

comment:2 Changed 18 months ago by taylor.smock

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.

comment:3 Changed 18 months ago by skyper

Description: modified (diff)

comment:4 Changed 18 months ago by skyper

Sure, I planned to change centre to center together with #21907 and #21964.
Are there more words to look at?

Last edited 18 months ago by skyper (previous) (diff)

comment:5 in reply to:  4 Changed 18 months ago by skyper

Replying to skyper:

Are there more words to look at?

So far I found "Neighbourhood" and "Theatre" beside many "Centre".

Last edited 18 months ago by skyper (previous) (diff)

comment:6 Changed 18 months ago by skyper

Owner: changed from team to skyper

comment:7 Changed 18 months ago by skyper

Changes are included in #21907.

comment:8 Changed 9 months ago by Klumbumbus

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 Changed 9 months ago by Klumbumbus

Owner: changed from skyper to Klumbumbus

comment:10 Changed 9 months ago by Hufkratzer

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


Another related discussion for iD:

comment:11 Changed 9 months ago by Klumbumbus

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. [ 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).
<div style="font-family:sans-serif">
  <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.

<div style="font-family:sans-serif">
  <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.

<div style="font-family:sans-serif">
  <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. 

comment:12 in reply to:  11 Changed 9 months ago by taylor.smock

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

That should really be generified for plugin use, but core translations are a bit more important.

comment:13 Changed 8 months ago by Klumbumbus

Milestone: 23.01

Milestone removed. Too much loss for too less benefit.

Modify Ticket

Change Properties
Set your email in Preferences
as new The owner will remain Klumbumbus.
as The resolution will be set.
to The owner will be changed from Klumbumbus to the specified user.
The owner will change to skyper
as duplicate The resolution will be set to duplicate.The specified ticket will be cross-referenced with this ticket
The owner will be changed from Klumbumbus to anonymous.

Add Comment

E-mail address and name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.