some new strings to separate (add context)

[aceman]

Please separate these strings for proper translation:

"pole"
item "Barriers/Fence" combo "Type" display value
item "Facilities/Clock" combo "Support" display value

"position"
item "Facilities/Toilets" combo "Position"
item "Facilities/Fire Hydrant" combo "Position"

"bicycle"
item "Shipping/Ferry Terminal" combo "Cargo" display value
item "Relations/General route" combo "Route type" display value
color bicycle

[stoecker]

In 6260/josm:

fix #9109 - separate contexts

[aceman]

Thanks. What about the "Position"?

[stoecker]

Replying to aceman:

Thanks. What about the "Position"?

See previous checkin.

[AlfonZ]

Replying to stoecker:

Replying to aceman:

Thanks. What about the "Position"?

See previous checkin.

In r6259 I can see values_context for Fire Hydrant. It seems to me that OP meant text_context.

[aceman]

Yes, I need the "Position" label itself, not the list of values.

[stoecker]

In 6262/josm:

see #9109 - fix hydrant text

[AlfonZ]

I don't think that removing values_context from fire hydrant's position is a good idea. It was there before - defaultpresets.xml@6258.

[stoecker]

In 6263/josm:

fix #9109 - never happy these users... Phew

[aceman]

Cool thanks :)

[aceman]

Still the speed you fix these bugs is very nice. Kudos to you guys! Other projects should learn from you :)

[stoecker]

It's not always like this. :-)

[aceman]

So now when you are warmed up, can you tell me what is the cycle for syncing the translations? When do all these changes get updated to the .po files (launchpad translator) and when do translations get applied to the JOSM source?

[stoecker]

Syncing is done each night at 03:00.

New translations are installed for each new release or on request when someone did lots of new texts.

[aceman]

That does not seem right because none of the changes made here are visible in the translation system yet (at least in SK language). Also in the previous cycle (before 6238) you were doing changes to strings the whole month but they only became visible in the translation system when the explicit merge was done just some hours before branching 6238 as tested release. So we had no chance to update translations for the release.

[stoecker]

Replying to aceman:

That does not seem right because none of the changes made here are visible in the translation system yet (at least in SK language).

A bug. The SVN repository was in lock state, so there was no update (which also affects the javadoc, the shortcut extraction, ...). Should be ok tomorrow.

Also in the previous cycle (before 6238) you were doing changes to strings the whole month but they only became visible in the translation system when the explicit merge was done just some hours before branching 6238 as tested release. So we had no chance to update translations for the release.

Yes. Was another bug in the translation extractor process.

At least once a year all these automatics show that they have an own opinion and fail silently :-)

[aceman]

Good that I have seen correctly:) Thanks for the explanation. I'll be happy when the system runs as you described. Those syncing times are enough for me :)

[aceman]

Uh, it was probably not necessary to add values_context="route type".
Not it has separated these 2
#. item "Public Transport/Public transport route" combo "Route type" display value
#. item "Public Transport/Route master" combo "Route type" display value

from

#. item "Relations/General route" combo "Route type" display value

Would you be angry if we merged these 3 again? They seem to be semantically the same with the same title preceding the combo.

You probably did it to separate "color bicycle". Can that be done in a different way? I'd even suggest to add context to all the "color" strings (they currently mostly work thanks to being lowercased). I can file you a separate ticket for that.

[aceman]

By merging the route types I mean maybe adding the values_context="route type" to the other 2 presets too.

[skyper]

Replying to aceman:

By merging the route types I mean maybe adding the values_context="route type" to the other 2 presets too.

So we do not need "route type" but rather use "color" or "mappaint" where needed for the colour descriptions. Right ?

[aceman]

In my schema I would keep "route type" and add it to all "route type" combos but also add "color" when needed :)

[skyper]

Replying to aceman:

In my schema I would keep "route type" and add it to all "route type" combos but also add "color" when needed :)

We try to add as less "*_context" as possible. I understand the call for "color" but do you really need it for bicycle routes or does it work without ?
It can get tricky to set the *_context on the right place.

[AlfonZ]

As far as I know, setting context for colors is not supported currently.
So to separate color bicycle it would be needed to set context to other usages.
Or, simply just rename the color.

[aceman]

Ok, so how do we proceed? I proposed to add the same context to all the "route type" combos.

[aceman]

I now see localization comments at "color bicycle" (and all other colors) like this:
color bicycle (applied for "bicycle=designated")
color bicycle (applied for "highway=cycleway")
color bicycle (applied for "highway=path, bicycle=designated")
color bicycle (applied for "highway=path, bicycle=official")
color bicycle (applied for "highway=path, bicycle=designated, foot=designated")
color bicycle (applied for "highway=path, bicycle=official, foot=official")
color bicycle (applied for "cycleway=lane")
color bicycle (applied for "cycleway=opposite_lane")
color bicycle (applied for "cycleway=track")
color bicycle (applied for "cycleway=opposite_track")
color bicycle (applied for "cycleway=opposite")

Maybe this already does the proper separation?
Anyway these new hints are great and thanks to anybody who added them. I could fix half of the color strings' translations as their usage is now more clear (the group of objects it applies to can be translated better than just the single word).

[AlfonZ]

Replying to aceman:

Maybe this already does the proper separation?

This doesn't separate them, just lists all usages of the color. The context separation is still done as before.

Anyway these new hints are great and thanks to anybody who added them. I could fix half of the color strings' translations as their usage is now more clear (the group of objects it applies to can be translated better than just the single word).

This was added in [o29999] of #9156. That was exactly the intent behind it. :)

[skyper]

Replying to AlfonZ:

Replying to aceman:

Maybe this already does the proper separation?

This doesn't separate them, just lists all usages of the color. The context separation is still done as before.

Well, it separates the entry for the colour part of preferences from the rest and we do not need the own separation for routes any more. Maybe we can drop some more *_context. Have to take a look at it.

[aceman]

I would suggest to keep the context for the route types and merge the 3 occurrences under this context. Because this combo contains values that will occur elsewhere sooner or later. So keep the context when we already have it.

If dropping any context causes the invalidation of the translation again (not sure why the "fuzzy" feature of .po files is not utilized to ease this problem), then I think it should be kept.

[skyper]

Ok, lets keep it until it is changed or the translation software can manage it.