<div dir="ltr">That's why using the extension is <b>optional</b> for translation. You can still use the old system if you believe a page should not be a 1:1 translation and English-based (though you can have the source page language in other languages).<br clear="all"><div><div dir="ltr" data-smartmail="gmail_signature"><div dir="ltr"><div><br></div><a href="https://wiki.openstreetmap.org/wiki/User:Lectrician1" target="_blank">lectrician1</a></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El mar, 26 abr 2022 a la(s) 09:05, Frederik Ramm (<a href="mailto:frederik@remote.org" target="_blank">frederik@remote.org</a>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
On 22.04.22 23:55, Seth Deegan wrote:<br>
> Voting for the proposal to add the Translate extension to the OSM Wiki <br>
> <<a href="https://wiki.openstreetmap.org/wiki/Proposed_features/Add_Translate_extension_to_Wiki" rel="noreferrer" target="_blank">https://wiki.openstreetmap.org/wiki/Proposed_features/Add_Translate_extension_to_Wiki</a>> <br>
> has now started.<br>
<br>
I see the voting has prematurely been aborted due to new information <br>
about the plugin.<br>
<br>
My main concern for voting against this proposal was that, from what I <br>
understood, the underlying idea is that<br>
<br>
* all information about all tags should ideally be the same in all languages<br>
<br>
* if something diverges from "the global information" in one language <br>
that diverging information must either be translated to English to <br>
become part of the "the global information", or at the very least it <br>
must be clearly identified which is the differing part so that it can <br>
somehow be isolated in a language-specific subpage.<br>
<br>
I am not sure if I have perhaps misunderstood something. One other voter <br>
who was in favour of the plugin has written: "I am voting yes so that <br>
the fledgling mapping community in Puerto Rico can more easily maintain <br>
Spanish-language documentation that recognizes their country-specific <br>
tagging nuances; so that developers in Vietnam don't need fluency in the <br>
wiki's particular dialect of English in order to interpret our data <br>
correctly; but most of all, so that we can try this out and see if it <br>
works for us. Unlike with a tagging proposal, we will have a very <br>
decisive solution if this turns out to be a terrible idea: uninstall the <br>
extension."<br>
<br>
The way I see it, the "fledgling mapping community in Puerto Rico" would <br>
first have to analyse the differences between what their current <br>
documentation says and what the English version says in order to then <br>
produce a document that describes the differences. Where those <br>
differences are nunances (for example, where the English version says <br>
that something "is usually done" and the Spanish version says it "should <br>
be done"), people will often not go through the effort to actually <br>
retain these flavours because it would sound silly to write down <br>
explicitly "for Puerto Rico, replace 'usually done' with 'should be <br>
done'" or so).<br>
<br>
In my mind, a move to this extension would massively impact the <br>
understanding of the wiki; it would cement the dominance of English, and <br>
every local information that diverges from the mainstream English would <br>
have to be explicitly asserted as a deviation from the mainstream, <br>
whereas currently someone can document something in their language <br>
totally independent of what is said in other langauges.<br>
<br>
This, in my eyes, represents a cultural change and the exact opposite of <br>
what the voter above painted in rosy diversity colours.<br>
<br>
Being a cultural, not a technical change, it will be impossible to <br>
simply revert it by deinstalling the extension.<br>
<br>
(The same commenter said, in a different context, that a 50% majority <br>
should be enough to install the plugin and anything else was setting the <br>
hurdle too high, again claiming that you can simply uninstall the <br>
extension if you don't like it. I think this is assumption is naive at <br>
best - unless concrete plans are presented how all the changes made in <br>
support of the extension would be rolled back with little effort.)<br>
<br>
In order for me to support the installation of this extension, I would <br>
have to have certainty that the aforementioned rosy language "the <br>
mapping community in Puerto Rico can more easily maintain <br>
Spanish-language documentation that recognizes their country-specific <br>
tagging nuances" is actually true and not just an excellent exercise in <br>
rhetoric. I want to see a concrete example how someone who speaks only <br>
Spanish, only German, only Polish, can go to their language's <br>
highway=path page and add some information there in their language...<br>
<br>
... WITHOUT having to navigate to a sub-section or sub-page that is <br>
reserved for language-specific stuff ("you can't edit the stuff up here, <br>
please go down there to add your information")<br>
<br>
... WITHOUT having to fear that something they added will be overridden <br>
by conflicting information a second person has added to the English page <br>
and a third person has translated to Spanish/German/Polish<br>
<br>
... WITHOUT having to first mentally dissect what the international <br>
standard is and how whatever they want to add diverges or not from the <br>
international standard and then clad it in appropriate markup<br>
<br>
I'm willing to be convinced but frankly, what I've heard until now seems <br>
largely marketing-speak and empty promises. "There will be some corner <br>
of the wiki where people can document special cases" is not enough. In <br>
fact, I even object to the idea that there is one standard documentation <br>
and then possible "divergence" from that. One voter in favour of the <br>
plugin writes "the LibreOffice wiki translation process is so much <br>
better now" and this explains quite well what I feel - I think there's a <br>
mindset that assumes OSM is some kind of software like LibreOffice and <br>
everything is about describing the features of this software. But <br>
tagging standards and conventions are the result of a social process, <br>
not the description of the capabilities of some software.<br>
<br>
And I think that everyone who says "let's just try that, we can always <br>
go back" knows full well that it will only be weeks until it will be <br>
impossible to go back.<br>
<br>
If we want to install this for a "trial" then we should clearly limit <br>
which pages it is to be used on (and those should not be tagging pages). <br>
Use it for a description of the API or the data model, or the history of <br>
OpenStreetMap or something. I can live with that.<br>
<br>
Bye<br>
Frederik<br>
<br>
-- <br>
Frederik Ramm  ##  eMail <a href="mailto:frederik@remote.org" target="_blank">frederik@remote.org</a>  ##  N49°00'09" E008°23'33"<br>
<br>
_______________________________________________<br>
talk mailing list<br>
<a href="mailto:talk@openstreetmap.org" target="_blank">talk@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/talk</a><br>
</blockquote></div>