Make Translations inviting

[Hb---]

The interested foreigner is led via Contribute directly to Translations. Currently this page

• is overloaded with statistics which do no help beginners but scare them
• starts with the hardest and most dangerous part at all. No novice would try to translate the Startup Page.
• hides the wiki translation as easiest part under the third subtitle. But a lot of users have edited Wikis elsewhere.

I would see the page like:

Introduction

1. Section with an inviting explanation for Wiki translation and a link to Translations/Wiki
2. Section about Startup page and software translation and a link to a new page with details for all that and all translation statistics

The then following main content can contain all language specific notes.

I did some structural change there. But before starting an edit war with responsible persons some more thoughts might be helpful.

[stoecker]

This page is meant as documentation, not as translator recruiting. If you want to create such a page make it separate (e.g. a sub page of this one or a sub page in the Help section) and link it from the start page.

I wish you good luck in this case as translators are always welcome, but I fear the success will be minimal. The "not enough translators" seems to be a common situation shared by many projects independent from the fact how good or bad documentation or the tools are.

The link from the start page was more or less a try to improve situation, but I've not seen a measurable result. Same for the percentage displayed on the start page.

[Klumbumbus]

I suggest:

• remove the section "Version history translation status" (nobody is interested in translating outdated stuff and the graphics are on each year page too)
• include the section "Version history" in "Startup Page"
• reorder the sections to:
  • Online help and Wiki pages
  • Software
  • Startup Page
  • Language specific notes

[stoecker]

Replying to Klumbumbus:

I suggest:

• remove the section "Version history translation status" (nobody is interested in translating outdated stuff and the graphics are on each year page too)

Not quite true. Some people are interested in history as well. You never get 100% without these ;-)

All these stats are only there to show translators a feeling of measurable results when they compare to other languages (seems not to work as well BTW). Otherwise all these stats simply could go to a stats page.

• include the section "Version history" in "Startup Page"

Unclear what you mean.

• reorder the sections to:
  • Online help and Wiki pages
  • Software
  • Startup Page
  • Language specific notes

Hmm, actually for us the most important point is the software itself. Otherwise I have no problem with reordering.

[Klumbumbus]

Replying to stoecker:

Replying to Klumbumbus:

• include the section "Version history" in "Startup Page"

Unclear what you mean.

Don't use a separate heading, but simply mention in the section "Startup Page" that the version history is a yearly the archive of the startup page.

(With the aim to make the Translations page less cluttered.)

[Hb---]

Replying to stoecker:

This page is meant as documentation, not as translator recruiting.

That is your educated view. But do newbies see it the same way? It is our first impression on interested people. I personally needed some days to accidentally find the explanation of @52-70 meaning at the bottom of the language selector.

_
Replying to Klumbumbus:

• remove the section "Version history translation status" (nobody is ... outdated stuff ...

Moving all statistics to a page were they don't scare new users seems the best solution

_
Replying to stoecker:

Hmm, actually for us the most important point is the software itself. Otherwise I have no problem with reordering.

Then we should offer translators a package of strings important for the software. Perhaps as subproject on Launchpad or so.

_
The survey in ​February 2017 on josm-dev gave some opinions:

1. The round-trip-time on Launchpad doesn't make fun, advocating transifex (My personal experience with them is bad)
2. Some languages have such an amount of untranslated strings (way over 9000) that discourages anyone new.
3. The most important strings can't be worked on first with the current JOSM-Launchpad configuration. Importance levels are:

3.a Visible JOSM UI and tooltips
3.b National imagery sources
3.c Visible plugins the translating user is interested in
3.d Error messages {0}: option ''{1}{2}'' does not allow an argument
3.e Plugins the user never heart of
3.f Map data elsewhere
4 Unnecessary need for an additional tool, advocating JENKINS/Translation+Assistance+Plugin
5 Cat-eats-mouse-Problem: The users who can translate would not do it because they know English well enough.
6 CemP²: A translated UI would hinder these users to seek help in the English speaking community
7 Source strings may not be translatable English, reaction from core team is fine but from plugin authors may lack
8 ​translation usage statistic, 61,6 % non-english Krauts rule

Results on the talk list were ​Zero.

Ideas were:
Separate the core, plugins and imagery(#12179) strings

[stoecker]

Replying to Hb---:

Replying to stoecker:

This page is meant as documentation, not as translator recruiting.

That is your educated view.

No. That is simply the intention I had with this page.

But do newbies see it the same way? It is our first impression on interested people. I personally needed some days to accidentally find the explanation of @52-70 meaning at the bottom of the language selector.

Actually I don't expect newbies to read or find that page. I always tried to use the method "please come and help, we'll tell you when something can be done better". I don't expect people to understand all the finer details before they can start, but I assume they learn these when they progress, like you stated above.

• remove the section "Version history translation status" (nobody is ... outdated stuff ...

Moving all statistics to a page were they don't scare new users seems the best solution

As said, probably it's better to simply create a new landing page for translators instead of changing the documentation page (which does not mean this page cannot be cleaned up as well).

Hmm, actually for us the most important point is the software itself. Otherwise I have no problem with reordering.

Then we should offer translators a package of strings important for the software. Perhaps as subproject on Launchpad or so.

Texts at Launchpad are ordered according to importance already.

1. The round-trip-time on Launchpad doesn't make fun, advocating transifex (My personal experience with them is bad)

Actually I also do not like Transifex and prefer Launchpad to fix the bugs, but this seems not to happen. My motivation to spend work at a Transifex move is thus a bit low.

2. Some languages have such an amount of untranslated strings (way over 9000) that discourages anyone new.

Jupp. But we can't reduce the number of strings. But our minimum requirement for inclusion in the core is 2000 core strings.

3. The most important strings can't be worked on first with the current JOSM-Launchpad configuration. Importance levels are:

See above. Starting at the beginning does this.

3.a Visible JOSM UI and tooltips

I don't know a method ATM how we could separate core strings into mainly visible and mainly invisible strings.

4 Unnecessary need for an additional tool, advocating JENKINS/Translation+Assistance+Plugin

That probably is also a no-go. I want to do it, designed it and started coding, but don't have time to finish it.

6 CemP²: A translated UI would hinder these users to seek help in the English speaking community

No. We have fairly easy methods to change the language temporary.

7 Source strings may not be translatable English, reaction from core team is fine but from plugin authors may lack

Only for the minor plugins. The major ones either are handled by us or by their authors.

Ideas were:
Separate the core, plugins and imagery(#12179) strings

Maybe we could solve most of the Launchpad trouble by doing that (it seems trouble is related to the database side per project) and the Transifex switch wouldn't be necessary. Infrastructure side for the split is already done. We'd only need to upload the 3 files separately and copy all the existing translations.

[Klumbumbus]

Replying to stoecker:

Separate the core, plugins and imagery(#12179) strings

Maybe we could solve most of the Launchpad trouble by doing that (it seems trouble is related to the database side per project) and the Transifex switch wouldn't be necessary. Infrastructure side for the split is already done. We'd only need to upload the 3 files separately and copy all the existing translations.

Separating would be great. I think it also makes sense to create at leat 2 more groups: preset strings and validator strings, as these are larger groups and people often would like to start their translation work on these topics.

[stoecker]

The translation table at the end of the English Translations page makes no sense. Rather than adding a strange table I suggest a link to any example in another language.

[Hb---]

Replying to stoecker

The translation table at the end of the English Translations page makes no sense. Rather than adding a strange table I suggest a link to any example in another language.

Three reasons to keep it there:

1. The table with the Language specific notes and suggestions in its current – and mostly empty – state can not be final, sure.

But as the Dutch example shows, the translator took the foreign English terms as suggestion to fill the gaps with the native ones. I think that the table in other languages will see a similar development.
1. This table can be a target for guiding links from external systems. See this suggestion in ​https://help.launchpad.net/Translations/Guidelines. Perhaps we have such a static guidance already and I did not find it.
1. It is a place to communicate. Currently I see no structured ways or means for the translators interested in one language to communicate with each other. We need a Meta Translation Bug for each language. A mailing list for JOSM translations would lack all benefits Trac has.

And tables like this support communication, only by the limited means of a wiki, but they do. (The English variant can solve the question if JOSM deals with elements or objects and what the difference between them is.) To give each translation a start the English page needs a prefilled hull.

Updated: See comment:13

[stoecker]

Replying to Hb---:

Three reasons to keep it there:

1. The table with the Language specific notes and suggestions in its current – and mostly empty – state can not be final, sure.
   
   But as the Dutch example shows, the translator took the foreign English terms as suggestion to fill the gaps with the native ones. I think that the table in other languages will see a similar development.

Which Dutch? There is no Dutch translation? You mean German?

2. This table can be a target for guiding links from external systems. See this suggestion in ​https://help.launchpad.net/Translations/Guidelines. Perhaps we have such a static guidance already and I did not find it.

As said, it makes not much sense. Which terms are special mainly depends on the language itself and is not really related to the English original The table you present is a stripped down version of the German table, which has been the result of work in German translation, but which in itself is not useful for non-German languages. It only can be an example how such a table may look.

3. It is a place to communicate. Currently I see no structured ways or means for the translators interested in one language to communicate with each other. We need a Meta Translation Bug for each language. A mailing list for JOSM translations would lack all benefits Trac has.
   
   And tables like this support communication, only by the limited means of a wiki, but they do. (The English variant can solve the question if JOSM deals with elements or objects and what the difference between them is.) To give each translation a start the English page needs a prefilled hull.

You assume that English table can be a template. Sorry, but it doesn't work that way. Languages are to different for such a simple measure.

[Hb---]

Replying to stoecker:

Which Dutch? There is no Dutch translation? You mean German?

Sorry, correct link is https://josm.openstreetmap.de/wiki/Nl%3ATranslations?action=diff&version=36&old_version=34

... Which terms are special mainly depends on the language itself and is not really related to the English original.

I doubt this. Especially because the original in Programmers English is not straightforward enough. By all the honor we have to give to the founders of JOSM, but sentences like [1] stress every translators mind. And this sentence is still three times on JOSM main screen. So such a table might be helpful to bring the different terms of the original together.

It only can be an example how such a table may look.

We agree.

[1] "Set the selected elements on the map to the selected items in the list above."
https://josm.openstreetmap.de/browser/josm/src/org/openstreetmap/josm/gui/dialogs/ConflictDialog.java?annotate=blame&rev=86#L72

[Hb---]

Replying to stoecker:

The translation table at the end of the English Translations page makes no sense. Rather than adding a strange table I suggest a link to any example in another language.

My reply to this in comment:9 proved bad. Better for translation is a separate glossary for each language. So the page Glossary was put up.