Proposal talk:Add Translate extension to Wiki

From OpenStreetMap Wiki
Jump to navigation Jump to search

information sign

This page might get busy so it's recommend enabling Convenient Discussions in your gadgets to make reading and replying easier.

Handling non-English content

All translations are based only on the English source. You cannot edit translated versions of pages.

I do not understand how non-English content without any translations is handled? Do you just keep the old page? What if it has a language prefix? --Tigerfell This user is member of the wiki team of OSM (Let's talk) 19:58, 29 July 2021 (UTC)

@Tigerfell: Yeah I forgot to account for this. You can use a different source language for translated pages. I would say that whatever is decided as the source language, if that page has a prefix, it should be moved to a page of the name without the prefix when the translation of that page without the prefix's translation is complete (or if there is no translation, this can be done immediately). --Lectrician1 (talk) 21:55, 31 July 2021 (UTC)
The point is that not every information in this wiki is acutally available in any language. Additionally, some pages do not need any translation like France/OSM-FR/CA 2019-02-03. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 18:43, 13 August 2021 (UTC)
To answer my own question, one would probably move a page like this from the current location to some subpage .../fr and not mark this page as ready for a translation but that is mainly a policy issue (how the wiki community wants to handle such cases uniformly) and not a technical matter. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 21:21, 22 March 2022 (UTC)

Contributing without English language skills

All translations are based only on the English source. You cannot edit translated versions of pages.

When translated versions of pages are not editable, this excludes users without English language skills from contributing. Whatever Pros might exist for the Translate extension, this single point alone makes its use completely unacceptable for the OSM Wiki in my opinion. --Lyx (talk) 08:35, 28 March 2022 (UTC)

I agree with that sentiment, however I think this could be solved by allowing anyone, at any time, to sever the "this page is a translation of X" connection and instead continue working on the page as a stand-alone language version. That way, people without knowledge of English would not be excluded. Someone who would prefer to re-establish the link "this page is a translation of X" would then have to ensure that the English "source" is properly updated with the content added to the formerly "translation" page. Of course this is only possible if language pages are allowed to deviate from the "original" but that is a requirement anyway, see my issue below. --Woodpeck (talk) 09:52, 28 March 2022 (UTC)
Yes, this sort of system would still be acceptable. We are not forcing people to use the Translate extension if they don't want to. They can maintain deviance in content by still using the old translation system pages. Lectrician1 (talk) 18:17, 28 March 2022 (UTC)
I am not (only) talking about users making language- or region-dependent changes to documentation in other languages than English. OSM tagging is constantly evolving, and documentation in the Wiki plays a role in shaping that evolution. In my opinion it is important that all users can participate in that development regardless of which language(s) they speak. Because of that I believe we need to enable users to extend existing documentation, and write new documentation, in their own language; of course other users would still be encouraged to translate these additions into other languages, especially into English. --Lyx (talk) 00:45, 29 March 2022 (UTC)
Okay, and they can still do that. They would just need to translate their contribution into English first. Consistency in documentation needs to be rooted somewhere or else we'll end up with one big mess of conflicting tagging documentation, which is what we have right now in addition to things not being completely translated. Lectrician1 (talk) 00:51, 29 March 2022 (UTC)
Please remember that we are talking about users that do not speak English. So if those users want to add to the wiki, instead of adding it right then, they first have to find someone who has sufficient language skills in both English and one language of the user wanting to contribute, explain to that volunteer what they want to change and hope that the translator they found adds the translation to the English version before they can add their own original contribution as a translation. I would expect this process to take days at best and more commonly take weeks or months. If I where in the place of that user, I wouldn't bother and simply give up on contributing. --Lyx (talk) 01:18, 29 March 2022 (UTC)
I wouldn't think so. People would see the "This is a translated version of <source page name>". They would then click on the page and see it is in English. They could then attempt to edit the source and add their machine-translated English contribution in the appropriate spot since they could recognize the page layout pretty easily. Even if it's not grammatically correct, someone else could fix it.
They could also always start a discussion on the translated or source page's Discussion page and others could translate what they are asking for to change.
I also explained that language communities on OSM should set up their own documentation as to how to go about translating content to English and who can contact in what channels in their community. Right now this documentation doesn't exist since translating on this wiki is a free-for-all. I do believe such pipelines can develop and successfully enable contributions by all, especially since there are already many English speakers in the many of the different language Contact channels. Lectrician1 (talk) 01:34, 29 March 2022 (UTC)
Good point. There are users here who translate from Spanish to Catalan and they don't know English.
I also know Polish users who are expanding documentation in Polish based on their experience in mapping, but who don't speak English well. They are expanding it for other Polish-language editors. maro21 22:07, 29 March 2022 (UTC)

Conversation resources

Resolved: Translating with the extension is optional. We do not have to retranslate all pages.

If I understand it correctly, all translations need to be re-done, right? Looking at German as the most common language behind English in this wiki (Note: Polish might have surpassed it), we are talking of at least 2000~pages starting with "DE:Key:" and "DE:Tag:" only. Is there a way to import existing translations to Translate Extension? --Tigerfell This user is member of the wiki team of OSM (Let's talk) 20:14, 29 July 2021 (UTC)

Yeah they all do need to be redone because of formatting and sync issues. There is no way to directly import. --Lectrician1 (talk) 21:55, 31 July 2021 (UTC)
I was just asking because I do not think that we have enough users to transition this manually. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 18:45, 13 August 2021 (UTC)

User rights

Resolved

I would suggest to assign the "translate" right to signed-in users because non-logged-in users can not edit the wiki. I doubt that you can actually translate content if you do not have the "edit" right.

MediaWiki seems to have a user group called "Translation Administrators". Do we need this, too? --Tigerfell This user is member of the wiki team of OSM (Let's talk) 20:19, 29 July 2021 (UTC)

I forgot users who aren't signed in can't edit. This is fixed.
About Translation Administrators, maybe.
I just gave the translate-messagereview and translate-manage permissions which the Translate Administrators have to the autoconfirmmed users. translate-messagereview allows for users to review translations, which can help determine the quality of translations. It also makes sure people do not self-review their translations (which they could do if they had this permission).
I'm not really sure exactly what translate-manage does. It says it allows "Allows users to update and manage message groups with web interface.".
Translation Administrators are given one role which is key to translation management called pagetranslation. Every time the source page is changed, the translations are going to have to be updated and this involves "remarking the page for translation" (this of course is to prevent vandalism of becoming present on both the source and translation pages or just mis-formatting causing the extension to fail at create accurate messages). Translation Administrators are going to have to be users who are at least semi-active and remark the pages. That, or we need a lot of them.
From what I see, we should probably have translation managers with the same permissions Mediawiki has. --Lectrician1 (talk) 21:55, 31 July 2021 (UTC)

Does it work in templates?

Resolved

(I am eagerly wishing for an improvement of the system for translating articles and hope that this proposal hasn't died yet.)

> "clutter the English text with various markers"

In the last discussion on the topic which reverted the 7 year old decision to introduce this extension, some contributors deemed the use of markers as required by this extension as "unacceptable and [a] no go". Nevertheless there exist masterpieces like Template:Generic:Map Features:sport. Is it possible to use the extension in templates? Such map feature overviews might be a good start for rolling it out since typical users don't have to edit them very often and the current status quo is a horrible mess anyway. --Nw520 (talk) 20:46, 10 March 2022 (UTC)

@Nw520 Yes! Please see Template:Translatable template. For an example page it is being used on, see: https://meta.wikimedia.org/wiki/Main_Page/en. Lectrician1 (talk) 14:10, 15 March 2022 (UTC)

Content deviating on purpose

On many pages we have content in a language-specific page that is not present in the "original" English page, and this is done on purpose because the situation in the target are of the language-specific page is different from the "generic" English page. In other words, many pages are more than just a translation and this is not a shortcoming but a strength. How would this be modeled in the future? --Woodpeck (talk) 08:08, 28 March 2022 (UTC)

Is it valid for a translated page to have different content? The use of tags can differ per region (which would warrant a note in all translations or a separate region-specific page), but surely not depending on the language the mapper reads documentation in? Translations of generic pages having a target region seems like a bug. It's to be expected that region-specific pages often exist only in one language of course. --JeroenHoek (talk) 10:12, 28 March 2022 (UTC)
"Is it valid for a translated page to have different content" Yes. For example
I would be able to list at least one example for nearly all larger pages in Polish. Pages should describe the same tag meaning, but there are many region-specific issues - and each region will have some issues of higher and lower importance. And ideally examples would use local context (this is trickier for languages used in many places across world like English or Spanish) Mateusz Konieczny (talk) 10:31, 28 March 2022 (UTC)
Most of your examples are Poland-specific, not Polish-specific though. The language related ones (like the 'bar'-example) are valid; does the proposed translation method block these? Adding a language-specific note to a translated paragraph should still be possible. --JeroenHoek (talk) 11:04, 28 March 2022 (UTC)
Many languages, including Polish, are nearly completely region-specific, often country specific. It makes sense to mention Poland specific things in Polish specific translation. Mateusz Konieczny (talk) 11:16, 28 March 2022 (UTC)
@Mateusz Konieczny In this case, making a section or subpage of Pl:Key:amenity for Polish-related uses of the tag at Pl:Key:amenity/Polska might be appropriate. That way the general documentation about how to use the tag is similar for all languages but in regards to usage of it in Poland, the documentation is specific for there. I could make or modify a template that links such a page to the main tag page. Lectrician1 (talk) 18:22, 28 March 2022 (UTC)
So documentation about Polish-language related aspects of amenity=bar would be on a separate page, right? Mateusz Konieczny (talk) 19:33, 28 March 2022 (UTC)
Correct.
Though we should probably try not do this. What if non-Polish speakers want to contribute amenity=bar to Poland? We shouldn't seclude mapping practices to those who only speak the language of that region. Including the Polish usage of the tag as a section on the original page or providing translations of the Polish page would be the best solution to this problem. Lectrician1 (talk) 19:40, 28 March 2022 (UTC)
Is it really a good idea to mention Poland/Polish-specific naming issue on Key:amenity listing and in translation into every single language? I definitely would not want to have on English (or Polish) page such discussion about false friends in German, Norwegian Bokmål, Urdu, Amharic etc Mateusz Konieczny (talk) 21:25, 28 March 2022 (UTC)
@Mateusz Konieczny: I wonder, would a Polish-speaking software developer encounter more difficulty understanding how the rest of the world uses a tag if the Polish-language documentation focuses on tagging practices in Poland? Or would that audience be expected to turn to something like TagDoc for a more data consumer–oriented view on tagging? – Minh Nguyễn 💬 20:58, 28 March 2022 (UTC)
(1) Polish documentation is giving such info in addition to standard basic info, not instead of it (2) part of that is flavor (for example using locally known brands in usage examples) (3) Any decent Polish-speaking software developer will be capable of using English language documentation, even if their spoken English is bad. Software documentation is only extremely rarely translated to Polish (using Polish variable names rather than English is sometimes happening but is considered as a sign of inexperience or very bad and poorly qualified programmer, at least among people I know) Mateusz Konieczny (talk) 21:18, 28 March 2022 (UTC)

@Mateusz Konieczny: Thanks for the context. I guess I'm used to the not-so-pragmatic approach in Wikimedia-land of translating as much as possible, even the API errors. Local color shouldn't be a problem as long as we're smart about choosing translation units on the source page. In my years of translating into Vietnamese at Translatewiki.net (the original Translate-powered wiki), I found countless opportunities to add Vietnamese-specific turns of phrase or Vietnam-specific examples. For example, any time a message referred to a deadline in UTC, I would add a gloss in UTC+7 for users in Vietnam.

I would recommend choosing translation units that encompass whole paragraphs. Many of the pages on this wiki that use {{LangSwitch}} are really, really bad about itty-bitty translation units that don't fit well together. It's a tradeoff: longer translation units means more opportunities for outdated translations. But Translate is flexible enough that we can choose longer translation units for some messages that are likely to be more stable and shorter ones for those that could change frequently. Projects that use Transifex, such as Vespucci and iD, are basically doing the same thing already.

 – Minh Nguyễn 💬 22:25, 28 March 2022 (UTC)

"does the proposed translation method block these". Apparently yes, it even lists "1:1 translations of pages" as primary benefit. I consider it as a primary problem and blocker Mateusz Konieczny (talk) 11:16, 28 March 2022 (UTC)
@Mateusz Konieczny Feel free to modify the Cons and Analysis sections to reflect this if you would like. Lectrician1 (talk) 18:14, 28 March 2022 (UTC)
@Woodpeck @JeroenHoek @Mateusz Konieczny Translated pages can only be based off of the original page in the original language. If we want to make pages for similar content that have content in different languages, then you would need to make a seperate page. Using you cannot translate and modify content from the same page.
For example, if we want Pl:Key:amenity to purposfully have different content than the source English page, then we should keep that old translation system Polish page and not convert it to a new-system page that uses the Translate extension. Lectrician1 (talk) 18:13, 28 March 2022 (UTC)

We should move content that is specific to certain areas and regions into paragraphs where it is highlighted that this is region specific content. Mappers from these areas which do not speak English should be put in a position where they can inform themselves about the meaning and usage of tags outside of their region (i.e. generic page translated in their language), and ideally we would translate this specific content also in English and other languages (marking it as region specific). This is also already done, albeit not to a great extent. —Dieterdreist (talk) 20:35, 28 March 2022 (UTC)

Another thing we can do is translated pages can be language-recognizing-transcluded on other pages. This way, if we have content that is important to a specific language on an English page, we can make sure it is translated into English and then transclude it on the English page and it will show up in English. Lectrician1 (talk) 03:01, 1 April 2022 (UTC)

Could we use sets of templates for language-specific extra content: something like {{#ifexist: [[Template:extracontent/{{PAGELANGUAGE}}]] | {{extracontent/{{PAGELANGUAGE}} }} }}? --Andrew (talk) 12:18, 1 April 2022 (UTC)

Sure? You can include anything you'd like on a source page. Lectrician1 (talk) 18:32, 8 April 2022 (UTC)

Comment from experience on other wikis

For people who have edited wikis using this extension such as Wikimedia Commons, Wikidata or the WMF Metawiki: What is your opinion of the extension and how have you found it? --Andrew (talk) 16:46, 28 March 2022 (UTC)

Is https://www.mediawiki.org/wiki/MediaWiki also using the same or something different? (my experience with it was horrifically bad and scared me away from editing) Mateusz Konieczny (talk) 19:36, 28 March 2022 (UTC)
@Mateusz Konieczny It is the same. Lectrician1 (talk) 18:12, 29 March 2022 (UTC)

I have three years of experience in translating OSM website on Translatewiki using this extension. The main difference is that these are translations for short messages - one word, one sentence - that are used on osm.org. Apart from adding translations for new messages I was mainly correcting other peoples' (random people not invloved in OSM) translations which were without context. There were a lot of errors due to the fact that random translators couldn't see where a particular message was showing on the website. It is translated in small portions, mostly single sentences without context. The context must be found by the translator. Unfortunately it took me several years to catch the fatal translation errors resulting from not knowing the context (i.e. where the message appears). These messages were translated by volunteers, often not using OSM at all. So let's say 2000 messages were translated by 100 different people, just because they know the language in question. In addition to translations errors, there were inconsistencies, i.e., the same term was translated differently by different people. This extension doesn't provide the context in which the sentence or word is translated, resulting in frequent translation errors. However, it is possible to add documentation (with hints where it is used) to each message, but that is extra work and an extra page to create.

Let's say that there is be a word "Argentinian" to translate into Polish using this extenstion. There will be probably many Polish speakers who know at least basic English and they'll translate it to "argentyński". But depending on context and place where is it used it can be:

  • argentyński
  • argentyńska
  • argentyńskie [+inflected forms: argentyńskich, argentyńskiego, argentyńskiemu, argentyńskim, argentyńskimi, argentyńscy, argentyńsku, argentyńską, argentyńskiej + variants with capital letters in case they start a sentence (you don't know it without context because the English word is always capitalised)]
  • Argentyńczyk [+inflected forms: Argentyńczykach, Argentyńczykami, Argentyńczykom, Argentyńczyka, Argentyńczykiem, Argentyńczykowi, Argentyńczyku, Argentyńczyków, Argentyńczycy]
  • Argentynka [+inflected forms: Argentynce, Argentynką, Argentynkę, Argentynki, Argentynko, Argentynkach, Argentynkami, Argentynkom, Argentynek]

The example from last month [1] where I found an error that had been there for 13 years. Simple translation, "relation" in English is "relacja" in Polish. But in this case this word was using in a sentence here: https://www.openstreetmap.org/relation/0 where there is "Niestety, nie odnaleziono relacji #0." These are the consequences of translating separate words or sentences instead of the whole article at once.

This extension is better suited for software translations and short pages that will not change often. Our tags documentation changes and grows frequently.

After enabling this extension here I can see a lot of new users, "volunteers" who would like to "help" by translating only the easiest and the shortest messages. maro21 22:36, 29 March 2022 (UTC)

@Maro21: I think you're pointing to one of the great unsolved problems of localization: choosing translation units large enough to be grammatically, stylistically, and pedagogically flexible – yet small enough to limit the impact of a given change to the source text. You're right that it's much more difficult to choose appropriate translation units for prose than for short UI text. It is not impossible to do it well, but it requires some foresight about the nature of potential future changes to the source text, as well as an adequate understanding of how major languages differ. There's no shortage of software developed by English speakers that make a mess of grammatical gender, those developed by speakers of Romance languages that rely too heavily on grammatical number, and those developed by CJK speakers that don't provide enough room for German words.

That said, I don't think this proposal needs to solve this industry-wide problem. The worst-case scenario is that a page needs to be converted back to a manual translation system. Indeed, most of the pages and templates that rely on {{LangSwitch}} have already chosen poor translation units, hampering both translations and improvements to the source text. If anything, this would be an opportunity to improve that situation.

 – Minh Nguyễn 💬 07:27, 24 April 2022 (UTC)

Example of page prepared for translation

Resolved: Example added and documentation expanded.
  • After a page has been marked for translation, using the VisualEditor for editing is not possible. This is a downside for new editors who don't know how to edit using Wikitext.
  • The auto-generated translation message dividers (<!-- T:1 -->) can get in the way of editing.

This combo may cause major problems. Can you show how Railways would look after such necessary conversion? I suspect that

  • It would become uneditable
  • Such conversion would take enormous effort

Mateusz Konieczny (talk) 19:44, 28 March 2022 (UTC)

Can you show how Railways would look after such necessary conversion?

@Mateusz Konieczny Added as a new video tutorial! Lectrician1 (talk) 04:15, 1 April 2022 (UTC)
Is there somewhere source code available as a text? Can you paste it to say Proposed features/Add Translate extension to Wiki/Railway page example? Mateusz Konieczny (talk) 12:03, 1 April 2022 (UTC)
@Mateusz Konieczny Done. Lectrician1 (talk) 13:47, 1 April 2022 (UTC)
If someone inserts a row between other rows in the table, then the whole translation has to be done again, right? Because then the order of the rows will change, so there will be new messages, even though they were already translated. maro21 18:07, 2 April 2022 (UTC)
@Maro21 No. It will just add those new messages. It can recognize text that hasn't changed and will retain those messages. Also, text that does change in messages does have to be completely re-translated. It will just mark the translation as outdated. Lectrician1 (talk) 20:01, 2 April 2022 (UTC)
Are these tags: <!--T:30--> added automatically or manually? maro21 20:13, 2 April 2022 (UTC)
@Maro21 Automatically. They are what separate individual messages. It's not recommended to move them. Lectrician1 (talk) 21:42, 2 April 2022 (UTC)
How this automatic process works? How text is split? (I was under impression that this <!--T:30--> need to be added manually) Mateusz Konieczny (talk) 07:44, 4 April 2022 (UTC)
@Mateusz Konieczny It does not say, but here is the documentation on them. Lectrician1 (talk) 13:51, 4 April 2022 (UTC)

Harmonize languages first

Resolved: See step 2 of conversion of typical pages.

Given that it is mandatory to have 1:1 matching pages, I propose to, before enabling such extension, to ensure that all content in other languages is present in English.

I suspect that it is impossible to achieve and in many cases harmful (which is my reason why I am suspicious about this extension).

But if that is possible and achievable and not harming wiki - then it should be done as the first stage. Mateusz Konieczny (talk) 19:46, 28 March 2022 (UTC)

See step 2 of conversion of typical pages. Lectrician1 (talk) 20:15, 28 March 2022 (UTC)
I know. My proposal is to start from it as I expect that this step will completely fail. And this way we will not end with deployed confusing extension that should be ignored by editors Mateusz Konieczny (talk) 21:20, 28 March 2022 (UTC)
@Mateusz Konieczny: Yurik attempted to identify some of the more structural discrepancies between languages when populating the data items some time ago. Many of these discrepancies remain in data items and can be identified by (intentionally bizarre-sounding) limited to language (P26) qualifiers. The idea is that they'd be replaced by limited to region (P48) qualifiers once both the data items and associated wiki pages are cleaned up. Obviously this audit didn't catch the less machine-readable nuances, but it's a start. – Minh Nguyễn 💬 21:03, 28 March 2022 (UTC)
limited to language (P26) is correct sometimes, because images are indeed limited to specific language documentations. maro21 22:44, 29 March 2022 (UTC)

"Tagging documentation pages rarely change"

Resolved: Text removed

There is a claim "Tagging documentation pages (which are the primary use of this wiki) rarely change, meaning that we really aren't discouraging many editors from making contributions by limiting editing to Wikitext."

I consider this claim as false and highly dubious. What is the basic of claim that making much harder to edit Wiki pages in English the harm will be small? And even if edits are done rarely - how does "we really aren't discouraging many editors" follow? Mateusz Konieczny (talk) 19:55, 28 March 2022 (UTC)

Okay, maybe it's a bad claim. Removed. Lectrician1 (talk) 20:13, 28 March 2022 (UTC)

Feedback from translators

Resolved: Notified translators and listed places on proposal

The proposal page is missing listing of places where you notified translators (you notified translators by posting also to non-English channels, right?).

If you have not notified translators who would be heavily affected by this changes you should use https://wiki.openstreetmap.org/wiki/Contact_channels listing to gather feedback and invite them to comment. Mateusz Konieczny (talk) 10:38, 29 March 2022 (UTC)

@Mateusz Konieczny Done in "External discussions" section. Lectrician1 (talk) 18:12, 29 March 2022 (UTC)
Thanks! At the very last Polish forum (maybe other languages) are also active Mateusz Konieczny (talk) 20:44, 29 March 2022 (UTC)
By "notify translators", I understand that people who are actively translating the Wiki (or were in the past) should know about this RFC, not people who are not involved in the Wiki. I don't know why the translators' work environment should be decided by people not involved in it. maro21 22:20, 29 March 2022 (UTC)
@Maro21 Do you have any suggestions of places where I can contact translators? I am not an internationally-involved OSM contributor so I truly don't know exactly where to post... Lectrician1 (talk) 18:00, 30 March 2022 (UTC)
Checking recently edited pages on OSM Wiki (say, within last year) and writing on their talk pages is an option Mateusz Konieczny (talk) 17:27, 31 March 2022 (UTC)
I think Talk:Wiki was a proper place (you've already done it). Mateusz's suggestion is also very good. But whether or not to use this extension should be decided by the people involved - that is, active translators, not outsiders or people not involved in translation. maro21 20:31, 31 March 2022 (UTC)

section "Working example in practice"

I added section Working example in practice where one can see how the extension works. So in this example every one can simply just translate a message "Thank you" without translating the rest of the text. So there will be situations that someone just translate "thank you" into one hundred languages and we will have a long list of languages. maro21 22:12, 29 March 2022 (UTC)

Thank you! I was going to do this soon but you beat me to it! Lectrician1 (talk) 18:01, 30 March 2022 (UTC)

What is the main purpose of this proposal?

Lectrician1, what is your purpose of adding this extension here? I'm asking to understand your intenstions better. I am surprised that such a suggestion is coming from someone who is not involved in translation here. Because I don't see your contribution to the edits on the keys and tags pages on the Wiki beyond discussions. And what is your experience with translating using this extension? maro21 22:56, 29 March 2022 (UTC)

@Maro21 I specifically don't translate on this wiki (into Spanish) because we don't have this extension. I don't ever want to take the time to annoyingly go line-by-line, side-by-side, translating large articles -- when in another 5 years all of my translations will be outdated and nobody would know.
I do however do translate on meta.wikimedia.org as they do have this extension and it's very easy to do. I want to bring that ease of translation to improve the wiki and OSM as a whole. Lectrician1 (talk) 17:58, 30 March 2022 (UTC)

Templates

Could you use the extension for multilingual templates that output text in multiple languages either for pages using the extension or for ones that don’t? --Andrew (talk) 19:54, 30 March 2022 (UTC)

@Wynndale Yes for both. Please see Template:Translatable template. Lectrician1 (talk) 20:10, 30 March 2022 (UTC)

Experience

To people proposing/supporting this idea: how large experience you have with editing pages describing tags/keys on OSM Wiki? How large experience you have with translating such pages?

Have you run into technical problems or confusing wikicode issues?

I admit that I worry about making even harder to edit pages. Already many people are scared away, and introducing additional layer of some magical comments and banning visual editor seems to be a problematic to me. Mateusz Konieczny (talk) 11:15, 31 March 2022 (UTC)

> how large experience you have with editing pages describing tags/keys on OSM Wiki?
A lot. See my user page.
> How large experience you have with translating such pages?
None as it's a pain without this extension. I do watch translated pages like ES:Procedimiento de propuesta.
> Have you run into technical problems or confusing wikicode issues?
No.
> I admit that I worry about making even harder to edit pages. Already many people are scared away, and introducing additional layer of some magical comments and banning visual editor seems to be a problematic to me.
Well, at least you can preview your changes with Wikitext. Switching to the 2017 wikitext visual editor could make Wikitext editing friendlier. Lectrician1 (talk) 18:29, 9 April 2022 (UTC)

Edits

What happens when someone makes minor changes - typo fix, better sentence structure etc. Is it invalidating translation?

What happens when someone makes substantial change - change in meaning or a full rewrite. Is it invalidating translation?

Is it possible to control whether edit will invalidate existing translations or request review from translators? Mateusz Konieczny (talk) 11:17, 31 March 2022 (UTC)

@Mateusz Konieczny If you want a change on the source page to be forwarded so that can be translated, the page must be "remarked for translation". Lectrician1 (talk) 18:48, 31 March 2022 (UTC)
I'm not sure if it happens automatically, but from my experience translating osm.org website, there were some errors in English language like "web site" instead of "website" which were not in translations of course. They were corrected and translations popped up as "not up to date". The only thing I had to do was to click "ok" to confirm the translation (which is not visible in any recent changes). So answering your question - probably yes: if someone forgot a comma, all translations will be not up to date. maro21 20:26, 31 March 2022 (UTC)

Articles are not 1:1 equivalents

Look at e.g. Pl:Tag:amenity=school - the article, although up-to-date and consistent with the English version, is written typically about Polish school types. The text includes pictures and maps with Polish schools. How would the translation of such a page look like in this extension? A bit in TranslateExtenstion and a bit in a Wiki editor? Because when translating in this extension there is no preview of how the page will look like, because there are no graphics, pictures or maps.

Of course I could also write about Polish schools in the English article, but:
- I don't see such a need, hardly anyone will use it
- it would be impossible to translate the names of Polish schools into English. And even in different English speaking countries the schools are called differently.
In the German article there could be information about schools in Austria, Germany and Switzerland.

Another argument is that there are Polish users who are expanding documentation in Polish based on their experience in mapping, but who don't speak English well. They are expanding it for other Polish-language editors. Then only the Polish version is edited. In the past articles were translating from German versions (because there has been big German community) by a Polish user (because he knows German, not English).

Another example:
Tag:amenity=post_office and Pl:Tag:amenity=post_office The Polish article is in my opinion complete and meets the needs of Polish users mapping in Poland. I don't see the need to translate long sections about how it is in India, USA and UK.

What I usually do is not even _translate_ from the English version, but create an article in Polish. It also happened to me to create pages in Polish that were not in English. Example: Pl:Key:building:colour and Key:building:colour.
This is how Wikipedias work - the articles about the same thing are not translations. Guess why there is no Translate extension for Wikipedias - because articles are big.

So that's one of the head arguments why I'm against it - that the articles are not and need not be IDENTICAL. maro21 20:56, 31 March 2022 (UTC)

@Maro21 The proposal just seeks to add the extension to the Wiki. Not every page must use it. In-fact, pages can use both the old and new translation systems if they want. That means Pl:Tag:amenity=school can remain if it wants to have deviating content from the English page and the English page can be a source page for the Translate extension so that it can be translated into other languages other than Polish. This means that the page will have a <languages> and {{Languages}} elements. Nobody is forcing you to use the extension.
Let me know if this needs to be clarified on the original proposal better and feel free to change the original proposal if you know how to do so. Lectrician1 (talk) 03:06, 1 April 2022 (UTC)
Proposed features/Add Translate extension to Wiki seems to be missing info about
  • possibility to opt out forever from conversion
  • info how opt out happens
  • what happens when some people want to opt-out and some do not
  • is it possible to opt-out temperamentally/indefinitely? How opt-out can be reverted?
  • is it possible to opt-out entire language?
  • How conversion from page translated with extension to opted-out works?
Mateusz Konieczny (talk) 12:08, 1 April 2022 (UTC)
@Mateusz Konieczny Okay, I think I have covered all of those questions in the new Usage section. Lectrician1 (talk) 16:46, 4 April 2022 (UTC)
Well, the problem is that this process mentioned is vague "consensus" while many languages will have two or three active translators, what should happen when they disagree?Mateusz Konieczny (talk) 17:56, 4 April 2022 (UTC)
Okay, added a paragraph to Agreement of usage about what happens when there is no consensus. Lectrician1 (talk) 18:38, 4 April 2022 (UTC)
"how conversion from page translated with extension to opted-out works?" seems to be not covered Mateusz Konieczny (talk) 17:56, 4 April 2022 (UTC)
Okay, clarified at Agreement of usage Lectrician1 (talk) 18:29, 4 April 2022 (UTC)
@Mateusz Konieczny Added at Switching from the new to the old translation system Lectrician1 (talk) 18:22, 9 April 2022 (UTC)
"if there are no objections after one week" - so any objection at all would stop it? So adding Polish specific content to Polish page could become vetoed by say, someone doing only Korean translation? Mateusz Konieczny (talk) 19:40, 9 April 2022 (UTC)
> so any objection at all would stop it
It's inferred that if there isn't consensus, people should follow the guidance stated above the sections what to do.
> So adding Polish specific content to Polish page could become vetoed by say, someone doing only Korean translation?
Edited and clarified they have to be from that language community. Lectrician1 (talk) 19:45, 9 April 2022 (UTC)
"pages can use both the old and new translation systems if they want" - it will come to such situations that there will be two templates - {languages} and <languages> and, let's say someone add a new translation in Spanish in a new system - there will be two Spanish translations, one made before and one made after. But translators of the old translation won't agree to remove their work. So there will be two different translations of the same article. A user won't know which they should click. maro21 22:17, 9 April 2022 (UTC)
Well, there has to be a choice to use either translation system or else if there's a disagreement, then the broader community needs to get involved. I tried to clarify this with this revision. Lectrician1 (talk) 02:17, 10 April 2022 (UTC)

Any further comments?

@Tigerfell @Lyx @Woodpeck @Maro21 @JeroenHoek @Nw520 @Mateusz Konieczny @Wynndale @Dieterdreist
Thank you all again for commenting and adding to this proposal! The proposal has become much larger and better as a result of your feedback!

I'm just pinging you again to ask if there are any other further comments about the proposal. If not, I will proceed with starting the 2-week voting on the 11th. Lectrician1 (talk) 18:51, 8 April 2022 (UTC)

At the very least, "How conversion from page translated with extension to opted-out works?" and https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Add_Translate_extension_to_Wiki#Experience remain not answered Mateusz Konieczny (talk) 23:18, 8 April 2022 (UTC)
I also disagree with "Maintaining deviating content is not recommended." part. As it is a new idea, maybe rephrase it as "Maintaining content which is not a direct translation of English page would become not recommended."? Mateusz Konieczny (talk) 19:38, 9 April 2022 (UTC)
Revised. Lectrician1 (talk) 19:53, 9 April 2022 (UTC)

How to watch?

How one would be able to watch the articles? Now there is only one page for one article. How many pages should you watch to follow the changes for e.g. DE:Key:access? maro21 21:57, 9 April 2022 (UTC)

@Maro21
If translators want to know when a new translation system source page is marked for translation, they should watch it.
Technically every translation message has its own page so whenever a user contributes a translation, they are added as a watcher of that translation unit and get notified when it changes.
So really, you don't need to manually anything to your watchlist as a translator. It's all done automatically.
You should read the Quality Assurance documentation for more info. Lectrician1 (talk) 02:27, 10 April 2022 (UTC)

regarding "Translate extension > Pros" section

  • "without translating an entire article" - This is a big problem. If the paragraphs are translated separately, it means that the article in Polish will look like this:

- paragraph in Polish
- paragraph in English (because it has irrelevant information from the point of view of a user of Polish language and Polish-speaking countries)
- paragraph in Polish
- paragraph in English (because it uses difficult vocabulary)
- paragraph in Polish
- paragraph in English (because it was too long and nobody wanted to translate it and it's been like that for a few years)

Personally, I prefer to see a short article, but all of it in Polish, rather than a situation where I click "Polish" to see an article in Polish, but see an article in 5% in Polish, with only the first sentence translated. maro21 22:02, 9 April 2022 (UTC)

Well then you can just not use the Translate extension in that case.
@Maro21 I totally agree with you with though. Some tagging pages do not require an in-depth explanation in all languages at the cost of using this extension.
I personally see this extension being of primary use for wiki documentation pages like Main Page and proposal process, and templates - which are places where content should be same. Lectrician1 (talk) 02:34, 10 April 2022 (UTC)

regarding "Overall" section

"By adding this extension we will benefit a significantly greater number of users by providing a better translation interface that will then encourage a greater quantity of quality and up-to-date translations." - this is an unsubstantiated wish. People are not going to appear magically out of nowhere, and the translation won't get any better. maro21 22:03, 9 April 2022 (UTC)

Fair. I'll leave it to the facts then. I removed the "Overall" analysis section. Lectrician1 (talk) 02:35, 10 April 2022 (UTC)

I'm against voting

In my opinion there should be only discussion here, no voting, because everyone can come here and vote, even new users and users not active on the Wiki and users that don't actively translate articles here. So why such people should decide about it? I don't know why the translators' work environment should be decided by people not involved in it. It's like having a stranger come into my office and decide what operating system we should use and let people from other company vote on it.

And I bet the voters won't even read this discussion because there is too much to read.
See: https://www.youtube.com/watch?v=fLJBzhcSWTk

I don't know how many people saw this proposal, but there were only a few active translators from this Wiki who wrote any comment. Voting without feedback from translators is pointless. maro21 13:55, 10 April 2022 (UTC)

  • To repeat question: have you contacted people translating on OSM Wiki? I worry that it can surprise and drive them away. See also #Experience section Mateusz Konieczny (talk) 14:36, 10 April 2022 (UTC)
  • @Tigerfell since you recommended the standard proposal process which involves voting, what do you think about this? Should we take or vote or leave it to discussion? Would you determine the outcome of the discussion?
@Maro21: I think you got a point. However, there is no other established method of reaching consensus available to me. Changing the method to reach consensus during or right before said method is going to be used is usually a bad idea. That is why I would like to stick to this established process. I am definitely open to contribute to a "wiki voting process" afterwards.

Would you determine the outcome of the discussion?

Definitely. I try to stay out of the discussion and remain neutral. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 20:03, 17 April 2022 (UTC)
Okay. @Tigerfell @Maro21 @Mateusz Konieczny I will be starting the voting tomorrow, April 22 and notify all places I notified about the RFC. Lectrician1 (talk) 16:47, 21 April 2022 (UTC)
@Mateusz Konieczny Do you have any preference?
My strong preference is to interview translators first, and ask them for feedback. Mateusz Konieczny (talk) 18:04, 21 April 2022 (UTC)
@Maro21 If you don't have any response to the responses about your feedback below and Tigerfell still recommends voting, I will likely proceed soon with starting it. Lectrician1 (talk) 19:53, 13 April 2022 (UTC)
I kind of have to agree with Maro that voting is not going to be representative of translators. But what do we have instead? IDK, it's kind of up to Tigerfell at this point then... Lectrician1 (talk) 13:27, 17 April 2022 (UTC)

My thoughts – why it's a bad idea

The goal I understand this idea is: "To have perfect and up-to-date translations in different languages". – this will never be fulfilled, no matter what translation system we choose (current, proposed or other) – because discrepancies will always exist. Some languages are active, others are not. The problem here is the very few people to translate (I think only the German version is the most active), not technical limitations. What you are proposing differs only in the fact that the missing translation will be marked with some color, and currently you have to visually compare two versions of a page or look in the history.

We haven't yet solved the problem with the vast discrepancies between language versions, just look at these categories: Category:Data item issues, especially Mismatched* categories, like Category:Mismatched onNode – it means that we have 600 pages that contradictorily suggest whether something can or cannot be mapped as a node, depending on the language! Almost no one cares, these categories should be empty.
One version says that something can be mapped as a node, another does not. Although we can assume that the English documentation is always the most important and valid, but the number of pages in these categories is growing instead of decreasing. We don't have many people to fix it.

I understand that we are aiming for articles in different languages to be consistent and not conflict with each other. However, this extension won't change that. As Data items showed well: in these categories we have thousands of conflicting tagging standards – the German version says I can tag it as a way, and the Spanish version says I can't. And nobody has cleaned up these categories so far, and the number of articles in them is growing.

  • The whole proposal is a utopia, that assumes that there is an army of translators who will translate everything in one go and there will be no inconsistencies between languages. People are always the weakest link, not technical limitations.
  • This won't make anything easier, only harder. We already have a lot of templates within the templates that make even an experienced user not know where to edit something to change.
  • This proposal assumes that articles in different languages must be IDENTICAL. And this is not and will not be the case. Everyone can write in their own words, giving examples from countries where the language is spoken. For example, the English page may contain an example from the American reality, where a chain of stores is widely known, such as Walmart. However, such an example will not be in the Polish version, because there is no Walmart in Poland, so the example will be tagging a store that occurs in Poland. I wouldn't like to read in Polish about local mapping standards in Indonesia or Switzerland. I wrote more about it here.
  • It's too late to implement such an extension. This might have been good in the early days of the wiki. The content on the wiki has grown a lot. Making a revolution will only create chaos. The Wiki has been around for 17 years, a lot of translations have been added, a lot of things are already here, and what is missing is manpower, not an extension to bring chaos to an already orderly world.
  • It's good to use it for short messages, but not for long articles. Everyone would translate 1/100 of the page and it will be a mess – different people will translate the same term differently, without even reading the whole article, without a context.
  • We have about 8400 tag and key pages in English, excluding other pages. There are longer and shorter pages but let's assume that writing one article takes one man-hour. So we will need another 8400 hours to process these articles, to WRITE THEM AGAIN. Add to this another man-hours to German and other languages. And consider that sometimes the people who write articles in English and in German are the same people. So at least few thousand hours to write again WHAT IS ALREADY written in the Wiki. Wiki is not complete and there are still many things to write. So if we had been discussing about this extenstion in the beginning of the Wiki I would have even voted for, but now, sorry it's too late.
  • I've been using this extension on TranslateWiki, and before I started translating the OSM home page there, I had to correct thousands of errors resulting from several hundred messages being translated by dozens of people, often unrelated to OSM and ignorant of what they were translating. I wrote more about it here.
  • This revolution will disrupt a well-functioning system of links on external sites, such as osm.org and iD and other, that link to articles in a given language.
  • The wiki has been around since 2005, most things are already translated into active languages. Even if adjusting the translation were to be a "copy-paste" job, it is still a lot of work. Who would do it? For example, for the Polish language, one user has translated more than 2000 articles for 9 years and is no longer active. Currently, there is practically no active user adding articles in Polish, and I'm not going to re-write them.
  • For me, as a long-time translator, it's easier to just copy paste an English page and translate it whole at once.
  • What I usually do is not even translate from the English version but create an article in Polish. I've also sometimes created pages in Polish that weren't in English.
  • I prefer to have only one sentence translated into other language, than to have one sentece translate and the rest of content in English.
  • This will not work with such a small number of Wiki editors. The problem with this Wiki is that there aren't many people to edit articles. For Polish currently I'm the only one who does 98% (but lately I've stopped caring about Polish articles and I'm more concerned with English content), some language don't even have active contributors.
  • TranslateExtenstion will not make more translators.
  • This extensions couldn't be used with long pages like Key:access or Multipolygon.
  • When I add new articles in Polish, I often improve the article and don't always edit the English version. This means that Polish articles are not the same as English ones, sometimes they are better.
  • Even the first paragraphs to tag articles in English are not uniform. But maybe the translators of a language have established one type of introduction and they are uniform, why spoil it?
  • We have a limited number of people willing to actively edit the Wiki. Enabling the extension and having to manually add <translate></translate> to each of the several thousand English pages will take time away from those active users who could be doing something else, like adding new pages.
  • To summarize, I don't see the benefit of introducing a revolution, except to introduce confusion into the existing order. maro21 14:05, 10 April 2022 (UTC)
@Maro21, my goal is to not create a revolution. It's optional for a reason: it's because I understand these concerns and agree with you. I simply want to use the extension on pages that are already 1:1 translations like on pages Proposal process and ES:Procedimiento de propuesta. For that page, @Dcapillae is required to watch it 24/7 and make the manual comparison for each edit. I applaud their edits greatly, but I hope that their work can be made easier by this extension.
This isn't complicated. I'm even willing to limit the usage of this extension to non-tagging pages if you want. Lectrician1 (talk) 16:07, 10 April 2022 (UTC)
From my understanding the goal of this proposal is to introduce a tool which may be used to simplify article translation and to define a framework of common rules for all languages with the possibility for each language's translation community to define additional rules if they deem it necessary. (For my taste that's too broad a degree of freedom, but it's the result of the discussions here) However, I do not perceive that this proposal's goal is “To have perfect and up-to-date translations in different languages” but rather to provide tools to simplify reaching this goals if an article fulfils certain criteria. Many counter-arguments apply to only a (though potentially big) subset of pages but, nevertheless, even when excluding those there's still a good amount of pages/templates that would benefit from it with considerably fewer drawbacks compared to other pages which is why I think that instead of focussing on whether this extension should be installed one should rather discuss for which pages it will be made available. What this whole talk page is discussing is whether the benefits outweigh the drawbacks for all pages instead of focussing on an area where the benefits clearly prevail.
  • “What you are proposing differs only in the fact that the missing translation will be marked with some color”
    • Missing and outdated translations are marked, which in my opinion is very valuable since without actually reading through both pages it's hard to spot discrepancies. Apart from that, the extension provides an interface that IMO makes translating actually easier (with the downside that there's the need for additional markup in the original/English page).
  • Markers and additional markup in original/English article
  • Problems with consistency between pages: “but the number of pages in these [maintenance] categories is growing instead of decreasing.”
    • I would claim that this issue is partially caused by the translation “system” currently in use. In order to create new translations one typically copies the (in most cases English) original page and translates its content. However, this copying of wiki markup includes all infobox parameters. Since infoboxes that solely source their data from data items are still the exception, this means that parameters like onNode, onWay, etc. are copied too. Now imagine an e.g. Luxembourgish-speaking contributor that thinks that amenity=waste_basket should be also applicable to lines. So they edit it on the Luxembourgish page but since the language's community is so small, nobody will notice that this change is actually undesirable and just like that we've got a desync.
      Central sources of truth (or two-way bindings, but there's no solution for that) – be it via data items or the translate extension – alleviate this problem. So one “issue” of the proposed extension “Thus, you cannot contribute to translated versions of pages.” might actually help curb the mentioned problem.
    • This is also the reason why I refuse to read German pages if there are English ones available since there's an impressive amount of pages that heavily deviate from their English counterpart.
  • “articles in different languages must be IDENTICAL”
    • No, they don't. One could easily write Lidl instead of Walmart. Apart from that, this proposal clearly states that each language's community is free to choose whether they want to use this system and there are guidelines in the proposal that explain when and how pages can switch to the current translation “system”. Even excluding such pages, Lectrician has already given some examples for pages that clearly should have identical content.
  • “Everyone would translate 1/100 of the page and it will be a mess – different people will translate the same term differently, without even reading the whole article”
    “I prefer to have only one sentence translated into other language, than to have one sentence translate and the rest of content in English.”
    • When a page hasn't been fully translated and still contains fragments of the original one, this can happen with the current “system” too.
    • I think what your argument implies is that with the current system one really can only translate a page in whole rather than “starting somewhere” and only translating let's say half of it. The extension would make such partial translations possible. And since the translation progress is displayed in the language navigation box readers (that are not interested in translating) can quickly determine whether it's worthwhile to switch from the original language to their native one.
  • „We have about 8400 tag and key pages in English […] So we will need another 8400 hours to process these articles, to WRITE THEM AGAIN“
    “most things are already translated into active languages”
    “We have a limited number of people willing to actively edit the Wiki”
    • You are assuming, that every page will have to be migrated. Even if that is desirable if this extension were implemented (as long as the page is deemed compatible for translating), would it be bad if only newly created pages and templates use this system?
  • „errors resulting from several hundred messages being translated by dozens of people, often unrelated to OSM and ignorant of what they were translating“
    • Since this extension would be installed on OSM-wiki one can generally assume that contributors have at least some basic knowledge on OSM.
  • “I often improve the article and don't always edit the English version”
    • As long as this only concerns phrasing this is mostly A-OK when using the extension. However, if for example new examples or sections are added I'd argue that it is actually better to enforce that such changes are communicated to the original page's contributors to avoid desyncs and potentially conflicting information between languages. This proposal states that language communities should develop a process for doing that. --Nw520 (talk)
"One could easily write Lidl instead of Walmart." - then it would not be translation anymore. Also, someone would need to maintain that the same transformation is used in different sections Mateusz Konieczny (talk) 22:46, 12 April 2022 (UTC)
@Lectrician1: From a technical point of view, is the extension able to cope with “minor” deviations such as replacing brand names (e.g. doesn't break translation suggestions, doesn't make the servers explode, etc.)?
If it is, then I don't think that there is a problem with using the extension for localisation instead of “just” translation. After all, Wiki Translation is named translation too.
“maintain that the same transformation”: This does apply to the current system too, except for when one assumes that pages are translated by only one person which indeed is incentivised by how translation currently works but IMO is not a good thing. Another question that comes to my mind is: In what way is it bad if such transformations are not consistent in a page? Of course, uniformity is desirable, but I would expect that the main intention of the sentences remains recognisable. --Nw520 (talk) 13:35, 13 April 2022 (UTC)
> would it be bad if only newly created pages and templates use this system?
I think it would, because there are links to documentation in various places: osm.org, iD editor and other which use the old system. maro21 21:34, 23 April 2022 (UTC)
Well no duh. That's why Upstream_changes exists and will be implemented... Lectrician1 (talk) 21:51, 23 April 2022 (UTC)

@Maro21 and Mateusz Konieczny: (Replying down here since the line-item rebuttals are getting messy.) I see a contradiction in the claim that Translate is problematic because of the inability to substitute a more relatable example when translating, but that one should not do so in a translation. Translators have taken liberties with prose since time immemorial so that the translation can be more understandable and relatable. It's important to distinguish between these differences and more substantive differences that would impact how people contribute to OSM or use OSM data. – Minh Nguyễn 💬 08:28, 24 April 2022 (UTC)

Translation in editors as this one (translating small chunks of text) is usually expected to be 1:1 translation, and in fact this proposal requires translations when using this extension to be an exact translation without such deviations. I agree with "Translators have taken liberties with prose since time immemorial so that the translation can be more understandable and relatable." and that is one of reasons why current system seems better Mateusz Konieczny (talk) 18:08, 24 April 2022 (UTC)

this proposal requires translations when using this extension to be an exact translation without such deviations

@Mateusz Konieczny Where does it say that? Lectrician1 (talk) 18:13, 24 April 2022 (UTC)
@Lectrician1: The proposal touts "1:1 translations of pages" as an advantage of the Translate extension. Mateusz Konieczny seems to have interpreted that more literally and granularly than you intended. That's why I suggested that we all clearly distinguish between normative and informative deviations from the source text. Projects on Translatewiki.net and Transifex have developed good practices around encouraging translators to take liberties when necessary. Most projects use the fake "qqq" locale to provide hints to translators about details in the message that can or should be more creatively tailored to the audience. This is feasible as long as the project doesn't choose translation units poorly ("Lego strings"). I sure have taken some liberties in translating StreetComplete in the past; I hope that's OK. – Minh Nguyễn 💬 08:03, 25 April 2022 (UTC)
Yeah I'm totally fine with slight deviations. Nothing can ever be a pure translation and nothing is really stopping you from making it your own translation either. I really don't care what people do. Lectrician1 (talk) 09:31, 25 April 2022 (UTC)
For start, paragraphs (or sections? or smaller parts?) are translated separately - so keeping track of changes affecting multiple paragraphs is nearly impossible. Also, I understood 1:1 translation as, well, 1:1 translation. Note also that when commented about need for different examples etc the response seemed primarily about that using the extension would not me mandatory. It is definitely something worth clarifying Mateusz Konieczny (talk) 08:18, 26 April 2022 (UTC)
@Mateusz Konieczny: In prose documents, I typically see a whole paragraph or a whole list as a translation unit, but anything is possible. Perhaps the "1:1" wording was meant to contrast with the current situation in which a translation is sometimes a completely unrelated and completely contradictory page. When the source message changes, the translation editor shows a diff of the changes to the source message since the last time the message was translated. Saving the translation causes the message to be considered up-to-date, even if you change nothing in the process (so it's easy to ignore an irrelevant change to the source message). Inevitably, a diff will get messy now and then, but it's a lot less confusing than a manual diff of the whole page as we typically do today. Choosing a smaller translation unit also makes it more likely to see suggestions from translation memory. Translation memory would probably be more common in non-tagging pages around here; it would be especially useful for closely related languages. – Minh Nguyễn 💬 02:25, 28 April 2022 (UTC)
"Perhaps the "1:1" wording was meant to contrast with the current situation in which a translation is sometimes a completely unrelated and completely contradictory page" - then maybe "matching" would be a better match? And clear statement are translators expected to translate the original text and meaning - or redact an equivalent with for example changed examples or additional context added. Mateusz Konieczny (talk) 05:42, 28 April 2022 (UTC)
@Mateusz Konieczny: "Analogous" is how I read that part of the proposal. I don't think it would be effective to establish a translation style guide in the same proposal that would introduce the extension. We don't seem to have a style guide here in general (compare Wikipedia's style manual), but that seems like the kind of thing that could be addressed separately if necessary. The /qqq locale is a more effective mechanism to communicate expectations or opportunities to translators on a per-message basis. It's also a good place to point out passages on other pages to keep in sync. For example, the notes for some message in Tag:place=town could link to the analogous message in Tag:place=village so that the definitions or examples for these tags don't overlap considerably. – Minh Nguyễn 💬 08:11, 28 April 2022 (UTC)
"In prose documents, I typically see a whole paragraph or a whole list as a translation unit" in at least some cases consistency would be be needed across paragraphs or sections if adjustments are allowed @Minh Nguyen: Mateusz Konieczny (talk) 06:24, 28 April 2022 (UTC)
@Mateusz Konieczny: Yes, that's just the typical case that I've come across, but I've also come across whole sections as translation units, or individual list items, depending on the situation. There's a fundamental tradeoff between consistency and customizability, and the translation units can be adjusted at any time to strike a better balance. Currently, we're at one extreme in treating the entire document as a single translation unit, maximizing customizability at the expense of consistency, but the Translate extension wouldn't force us to go all the way to the other end of the spectrum. – Minh Nguyễn 💬 07:56, 28 April 2022 (UTC)

Notice to translators

This is a ping to notify all of the people who have contributed to language-namespace pages over the past 30 days about this proposal to add the Translate extension to the Wiki. I used this filter to find you all.

I don't think this is going to ping everyone and I didn't get everyone on the list, but if you know other translators who should be aware of this proposal, please notify them.

@Taktaal @Kioska Journo @Grass-snake @Kjon @Angoca @Goodidea @Misc @Wguayana @Das-g @Geonick @Netzach @Barnes38 @AndriesWijma @Mapeadora @LySioS @Javiersanp @Nyampire @Tokada @Thepacki @Markus B @Eiskalt-glasklar @Thetornado76 @Hayashi @AgusQui @Rurseekatze @stc @Cquest @nathanbnm @Sean de Basti @Nomada @Literan @Hugoren Martinako @Gontsa @Jeisenbe @Puma515 @Dooley @Jynus @legofahrrad @Geozeisig @Vinber Lectrician1 (talk) 18:17, 10 April 2022 (UTC)

Language-specific transclusions

Resolved

Is it possible to have language-specific transclusions? If they were possible, I think having those would make it possible to still allow region-specific text in pages. Let's say we have a template {{Section local}} that is inserted in the original page. Assume we're reading the Luxembourgish translation of Tag:amenity=waste_basket.
The template would check whether Tag:amenity=waste_basket/lb/Local exists. If it does the template emits a translated section title and transcludes the subpage's content, otherwise nothing is output. --Nw520 (talk) 12:29, 11 April 2022 (UTC)

@Nw520 Yes. We can put {{#ifeq:{{SUBPAGENAME}}|lb|{{Tag:amenity=waste_basket/lb/Local}}}} on the source page and it will transclude Tag:amenity=waste_basket/lb/Local only on the Luxembourgish translation. Lectrician1 (talk) 13:45, 11 April 2022 (UTC)
Seems like {{#ifexist:/Local|{{/Local}}}} is sufficient. Just noticed, that Andrew already suggested that in #Content deviating on purpose so sorry for the doubling. --Nw520 (talk) 16:33, 11 April 2022 (UTC)
Note that it would really increase technical complexity of editing Mateusz Konieczny (talk) 20:35, 23 April 2022 (UTC)

Comments from a developer

I am the original developer of the Translate extension. I am not a frequent user of this wiki, but I have contributed in the past, even on this topic. I got a link to this proposal and there are a few things that I would like to mention:

  • Starting with MediaWiki 1.38 (this wiki uses 1.35), editing translatable pages with the Visual Editor is officially supported. The translation mark-up will be visible, but otherwise visual editing works as with other pages.
  • The Translate extension comes with Special:PagePreparation to suggest initial translation mark-up and Special:PageMigration which may help migrating existing translations to the new system. We haven't gotten much feedback about these pages, so I don't know how well they still work.
  • The Wikimedia Language Team releases MediaWiki Language Extension Bundle which includes the Translate extension and which is compatible with two latest stable MediaWiki releases. I do not recommend using the 1.35 version of Translate because it would provide sub-optimal experience. There have been many fixes and improvements since then, including built-in support for translatable templates.
  • There aren't many free machine translation services, most of the services have fees and require a key. The Translate extension provides integration with them if you provide a key.
  • The database-based translation memory has limited features, and the "proper" ElasticSearch-based version has some known scalability issues. We are investigating options for improving the translation memory, which now works best for short strings only.

--Nikerabbit (talk) 15:12, 25 April 2022 (UTC)

Damn. Well this changes the game. Thank you for your response and thank you for developing the extension!
I think a lot of people already voted with the cons of the extension in-mind and with these details some of them have changed. Changing the proposal is not really supposed to be done during voting, so I'd reccomend stopping the vote, revising the proposal, and then starting a revote. I'd really like a revote anyways since the feedback given from the votes shows that a lot of people are confused about where the extension is proposed to be used. @Tigerfell sounds good?
Also, @Nikerabbit do you know if there is a test wiki already or maybe a Wikimedia-hosted test wiki that can be up 24/7 for users to try the extension on? I'm hosting it intermediately for users to try and it's not the greatest solution. Lectrician1 (talk) 15:31, 25 April 2022 (UTC)

@Lectrician1: The feedback from Nikerabbit gives you an opportunity to withdraw this proposal and save face. After all, many of the votes against the proposal were based on a cost-benefit analysis that was evidently flawed. The 1.38 requirement also buys you some time to refocus the proposal on the less controversial aspects while giving people a chance to cool down. Installing the extension per se would've been more tractable if we had allowed its adoption to be organic and left any formal process for later as necessary.

For the next go-around, would you still use the tagging proposal process? Tigerfell only suggested getting a majority, not the 75% supermajority threshold you chose in this vote. However, you've already set a precedent, so it may look bad to choose a different set of rules just because it came up short. It amuses me that a 60% supermajority is enough to change the constitution of some countries but not enough for the completely reversible act of installing an extension.

 – Minh Nguyễn 💬 20:09, 25 April 2022 (UTC)

@Lectrician1: If I understand you correctly, you assume that the current MediaWiki configuration can be updated to version 1.38. MediaWiki 1.38's stable state is announced for May 2022. I was told that switching from the LTS versions to the stable versions was not a problem. However, other programs or features sometimes gave headaches to the system admins. I remember issues with Composer, PHP, and MySQL. I suggest to ask the system administrators if there is something that hinders the update. Using e-mail (operations at osmfoundation) is probably the best contact channel. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 11:27, 26 April 2022 (UTC)
@Lectrician1 Could you send me an email or direct message to discuss testing wiki options? Nikerabbit (talk) 13:40, 28 April 2022 (UTC)
Thanks, that is a great info! Especially that visual editor is not banned changes a lot. Mateusz Konieczny (talk) 08:16, 26 April 2022 (UTC)

The Translate extension comes with Special:PagePreparation to suggest initial translation mark-up and Special:PageMigration which may help migrating existing translations to the new system. We haven't gotten much feedback about these pages, so I don't know how well they still work.

@Nikerabbit The reason I did not recommend using Special:PageMigration is because that would require moving all current translations of a page to the new subpage system and we likely do not want to use the Translate extension for all translations. It's really annoying that you cannot migrate a page after marking a page for translation. What would be optimal is you can migrate a page that has not already been moved to the new language subpage after marking for translation. For example, you would be able to put in ES:Procedimiento de propuesta into Special:PageMigration and then it would move the page for you and migrate the translations to Proposal process/es. Lectrician1 (talk) 00:56, 2 May 2022 (UTC)

Going back

Is it expected that this extension can be removed? If yes - how it would be done? Mateusz Konieczny (talk) 12:10, 28 April 2022 (UTC)

@Mateusz Konieczny: I think it would be prudent to consider the impact of uninstalling any extension that isn't part of MediaWiki Core or the set of extensions that ships by default with MediaWiki, even if there's consensus that it's a very nice extension. At the least, if we have to temporarily disable the extension in an extenuating circumstance, there won't be as much surprise about workflows that suddenly stop working as expected. I've written a few words on the subject on the mailing list [2], but I only have experience using the Translate extension, not managing it, so it's possible that I've missed some detail. – Minh Nguyễn 💬 21:13, 28 April 2022 (UTC)

New roles

From mailing list by @Minh Nguyen: "Translation administrator is a distinct user group in MediaWiki. The revised proposal should describe how we want to assign this right to users. Should it be a subset or superset of the administrator group? Should we choose translation administrators from a broad selection of active languages? Existing deployments have policy pages that could serve as a starting point."

So if restarted the proposal should clarify how this new roles would be assigned Mateusz Konieczny (talk) 19:30, 28 April 2022 (UTC)

Here's my full post on the mailing list: [3] It would be nice to get this detail sorted out ahead of time, even if it would fall back to administrators by default. Wikibase also came with its own role, data administrators. For both extensions, filling the roles with some non-administrators could help lessen the burden on the administrator team and help the extension better live up to expectations. – Minh Nguyễn 💬 21:10, 28 April 2022 (UTC)
@Mateusz Konieczny @Minh Nguyen This was already present in the original proposal in Configuration... Lectrician1 (talk) 11:55, 29 April 2022 (UTC)
@Lectrician1: Ah, I was searching for "translation administrator" (the group used on Wikimedia wikis) but came up empty. It didn't occur to me that these individual rights would be assigned to existing groups. Sorry for the confusion. Assigning translate-manage and pagetranslation to all autoconfirmed users certainly lessens the load on administrators, but others have expressed a concern about overzealous language enthusiasts marking everything for translation too aggressively. Creating a separate user group would be handy, even if the process for naming new translation administrators is as simple as someone asking for that right. Then at least administrators could strip that right to enforce a cooling-down period. – Minh Nguyễn 💬 16:42, 29 April 2022 (UTC)
@Minh Nguyen Okay, a translation administrator role has been proposed. Lectrician1 (talk) 03:07, 2 May 2022 (UTC)

New page for revisions

@Lectrician1: The revisions you're making to the proposal are an improvement in many ways, but maybe it would be cleaner to draft a new page with the revised proposal and revert this page back to how it was at the time of the vote. A lot of "redux" proposals are presented to the community that way. Also, the proposal seems to consist of some parts that you particularly need the community's feedback on, along with other parts that are just there to explain how the extension works. If you move the explanatory content to a subpage, as an appendix, then the most pressing questions will be front-and-center for voters to consider, and perhaps there will be less of a sense that what's being proposed is too complicated. – Minh Nguyễn 💬 07:38, 2 May 2022 (UTC)

but maybe it would be cleaner to draft a new page with the revised proposal and revert this page back to how it was at the time of the vote

@Minh Nguyen I thought about doing this but I decided not to because that wouldn't preserve the page history of the proposal and it would require distributing a new link, etc. I can link the previous proposal revision on the current proposal page if you want.

Also, the proposal seems to consist of some parts that you particularly need the community's feedback on, along with other parts that are just there to explain how the extension works.

Can you elaborate on "the parts need the community's feedback on"? I don't really understand what you mean.

If you move the explanatory content to a subpage, as an appendix, then the most pressing questions will be front-and-center for voters to consider, and perhaps there will be less of a sense that what's being proposed is too complicated.

And these are? Lectrician1 (talk) 23:46, 2 May 2022 (UTC)
@Lectrician1: You've put a lot of effort into step-by-step explanations, screenshots, and screen recordings in this proposal, which is really helpful. However, these sections and to some extent the "Usage" section would inherently come with the Translate extension, whereas other parts are specific to this proposal and thus easier to miss. For example, I think the provisions for migrating a page to the Translate system and setting up the translation administrator group end up being important details easily lost amid the arguments in favor of adopting the extension in the first place. Structuring the "Translations system comparison" section as a table would also help by making the proposal more navigable. Anyways, these are just some suggestions, but not showstoppers either way. – Minh Nguyễn 💬 06:30, 3 May 2022 (UTC)

However, these sections and to some extent the "Usage" section would inherently come with the Translate extension, whereas other parts are specific to this proposal and thus easier to miss.

@Minh Nguyen The goal of the reformatted proposal is to let the reader deduce and judge the benefits and costs of implementing the extension. I know this is less concise than the Pros/Cons format, but it offers a structure that allows one to directly compare the systems' differences - something the Pros/Cons format could not. If you think that I should be more direct about the costs and benefits of specific features, feel free to edit the proposal to express those thoughts or let me know and I will change it.

For example, I think the provisions for migrating a page to the Translate system and setting up the translation administrator group end up being important details easily lost amid the arguments in favor of adopting the extension in the first place.

I mean, it is noted and linked in Translation page creation that translation administrators are required to enable a translation - inferring that users should click the link and learn about translation administrators. If you think this needs to be pointed out more, I can bold it or you can change it in another way.

Structuring the "Translations system comparison" section as a table would also help by making the proposal more navigable. Anyways, these are just some suggestions, but not showstoppers either way.

A table cannot fit the current images though. Lectrician1 (talk) 20:41, 3 May 2022 (UTC)

Language namespaces

The Translate extension was originally designed for translations to be subpages of the source page, which would be incompatible with the approach historically taken by this wiki. For better or worse, this wiki has relied on dedicated language namespaces for a small set of European languages and Japanese, along with pseudo-namespaces in the main namespaces for all other languages. I personally find the subpage approach to be easier to work with in many ways, and I really look forward to being able to filter search results by language. However, other users have probably built up a lot of muscle memory around the existing system. Is there any way to, say, make a Spanish translation use the ES: namespace instead of the main namespace or have the former redirect to the latter? If not, we'll need to update quite a few templates and data items, and taginfo will need to start looking for these translations in a different place than before. – Minh Nguyễn 💬 06:36, 3 May 2022 (UTC)

The {{Langcode}} template knows about the language tag set in the page properties; no more work is needed if it is set reliably from extension-translated pages. Modules that parse page names to determine the language would need to be reworked. Documentation page names can be handled through the data items; if we do that now for the links in {{Tag}} and Map Features templates, it optimises Map Features (some languages such as Danish are nasty) regardless of whether we install the extension. Andrew (talk) 12:17, 3 May 2022 (UTC)

Any more comments for proposal #2?

@Tigerfell @Minh Nguyen @Maro21 @Nw520 @Wynndale

Are there any more comments about the revised proposal?

Should I announce another period of RFC or should I proceed directly to voting? Lectrician1 (talk) 19:22, 13 May 2022 (UTC)

@Lectrician1: We're still on MediaWiki 1.37; would it be counterproductive to vote again before an upgrade to 1.38, which would address VisualEditor compatibility? – Minh Nguyễn 💬 22:20, 13 May 2022 (UTC)
Okay, I think I'll just announce the new proposal and the start of the vote then when 1.38 comes out. Lectrician1 (talk) 23:43, 13 May 2022 (UTC)
I just briefly skimmed the new proposal. It might be beneficial to explain how language-specific content is handled. You just wrote in the lead section that there is some solution but I missed more details.
There are multiple approaches to translate templates. You just named one of them. I recently documented the approaches at Wiki Translation#Template. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 19:00, 15 May 2022 (UTC)

It might be beneficial to explain how language-specific content is handled. You just wrote in the lead section that there is some solution but I missed more details.

Can you elaborate where I explained this and where I need to add more details?

There are multiple approaches to translate templates. You just named one of them. I recently documented the approaches at Wiki Translation#Template.

Thank you. I was not aware of the second approach. I have documented the approaches in #Translating templates#Current system Lectrician1 (talk) 20:27, 21 May 2022 (UTC)
@Tigerfell Lectrician1 (talk) 20:27, 21 May 2022 (UTC)
Great! In section Changes and clarifications since the previous proposal you wrote "Pages translated using the Translated extension do not have to be 1:1 translations. In fact, translations can add different content if they want to" this is explained in section 2.2.2. I missed that earlier. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 21:52, 21 May 2022 (UTC)
Yes. What did you change here? Because it's hard to parse and what I see is that you removed pros and cons that I and Mateusz added. maro21 20:39, 18 May 2022 (UTC)
@Maro21 As I explained to Minh above:
> The goal of the reformatted proposal is to let the reader deduce and judge the benefits and costs of implementing the extension. I know this is less concise than the Pros/Cons format, but it offers a structure that allows one to directly compare the systems' differences - something the Pros/Cons format could not. If you think that I should be more direct about the costs and benefits of specific features, feel free to edit the proposal to express those thoughts or let me know and I will change it. Lectrician1 (talk) 21:39, 19 May 2022 (UTC)

FYI: Wikimedia Diff post about compatibility with VE

Mediawiki 1.38 brings support for editing translatable pages with the visual editor, 12 May 2022, Isabelle Hurbain-Palatin --Nw520 (talk) 21:43, 16 May 2022 (UTC)

Post-discussion

@Tigerfell I set the status as Approved prematurely but please confirm that you see consensus as this is the procedure agreed upon.

Next, we just need to follow the Implementation Plan so if Tigerfell or @Minh Nguyen wants to create a PR to add the extension to the Wiki and if @TomH can upgrade the Wiki to 1.38 so that the features of the Translate extension can be implemented, that would be great.

I'll handle all wiki documentation and templates. Feel free to help or change edits I make. Lectrician1 (talk) 00:45, 16 June 2022 (UTC)

Note that it was not a vote, so I would put much lower weight on pure votes that gave no substantial reason for their opinion, making it not-so-onesided Mateusz Konieczny (talk) 05:38, 16 June 2022 (UTC)
I asked to an update of MW and the installation (https://github.com/openstreetmap/operations/issues/649). --Tigerfell This user is member of the wiki team of OSM (Let's talk) 23:18, 19 June 2022 (UTC)
MediaWiki has been updated to 1.39 so that blocker is now resolved. --Nw520 (talk) 11:23, 18 January 2023 (UTC)
Since #749 solve, is there any continue effert on this translate plugin? --快乐的老鼠宝宝 (talk) 14:08, 7 April 2023 (UTC)
I think you used the word "consensus" incorrectly. "Consensus" is "an opinion that all members of a group agree with". There is no consensus here, you confused it with the word "majority".
The section in this proposal was "Comments", not "Voting". 12 people just typed the signature with no comments. Their signature should not be taken into account because they didn't write any comment and it wasn't a voting. maro21 12:30, 26 June 2022 (UTC)

Their signature should not be taken into account

Highly questionable. One would assume that having 15 pages of condensed pro and contra would suffice as argument. Similarly, I could argue that some of the arguments that you've copy-pasted from the previous iteration and the pre-vote discussion have already been refuted and yet it would never occur to me to dispute the value of your vote. --Nw520 (talk) 12:49, 26 June 2022 (UTC)
Which arguments have been refuted? maro21 20:19, 28 June 2022 (UTC)
@Maro21: For what it’s worth, I think you’ve confused consensus with unanimity, which is a higher standard. – Minh Nguyễn 💬 02:37, 30 June 2022 (UTC)

Translating interface messages

Once this extension is installed, we should consider enabling it on certain pages in the MediaWiki: namespace that represent interface messages specific to this wiki (as opposed to being built into MediaWiki). The current system for translating these messages requires translators to manually copy-paste a long list of messages and nag an administrator to manually copy-paste each translated message into a separate MediaWiki: page. We can't really promote translation of interface strings in general, because there's no centralized listing of them.

As a result, key parts of this wiki remain untranslated or undertranslated. A good example is MediaWiki:Mapfeatures, which is part of the sidebar of links. This is a link we want every visitor to the wiki to understand, but so far it's only been translated into 15 languages. Some of these messages also appear in templates such as {{Languages}} and {{Taginfo2}}, where they help to make the wiki more usable. MediaWiki:Sitenotice hasn't been used for years but could become more useful if we could have any confidence in it being translated promptly. As an administrator, I hesitate to introduce new initiatives like souped-up 404 pages out of fear that they'll remain hidden to users of languages other than English. (These 404 pages are currently only available in English, Spanish, Vietnamese, and pseudo-German.)

Things are a lot better on wikis with Translate installed. For example, on Wikidata, if you're authorized to translate messages, you can view and translate from a consolidated list of all the messages that have been marked for translation, including a group of high-priority interface messages. When the base message needs to change for some reason, translators have an easy to way to detect the change and respond by updating (or not updating) their translations. It only took me a few minutes to translate d:MediaWiki:Gadgets-prefstext into Vietnamese on my own and see it reflected in d:Special:Preferences#mw-prefsection-gadgets.

I think the use of Translate in the MediaWiki: namespace will prove beneficial and avoid the controversy around its potential use on tagging pages. Unlike with tag description pages, there's no migration path to consider, since Translate is an offshoot of the interface message system in the first place. All existing translations will continue to work as is. Most of these messages are inherently location-neutral; there's little risk of a mapper community in one country needing to preserve the ability to unilaterally deprecate the {{Purge}} button or somesuch.

 – Minh Nguyễn 💬 03:31, 2 July 2022 (UTC)

So ist this going to happen?

Voting is closed for three months now and nothing seems to have happened since. What is the current status of this? Discostu36 (talk) 20:44, 24 September 2022 (UTC)

@Discostu36: There's a ticket in the OSM operations' issue tracker. Lectrician1 has asked 3 days ago about the status of the installation and was told that it's currently blocked. I suppose that's due to the wiki having to be updated to Mediawiki 1.38 and the currently installed and activated MultiMaps extension breaking starting with that version. --Nw520 (talk) 23:05, 24 September 2022 (UTC)
Lectrician1 has created a pull request in February which was finally acknowledged by one of the repo's maintainers about half a year later. --Nw520 (talk) 11:07, 3 August 2023 (UTC)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal_talk:Add_Translate_extension_to_Wiki&oldid=2580503"