The"visual editor"used by the complicated Parsoidis already accessible to the public , it is the "wysiwyg" that - without thinking it would be so complex - I asked Jim Wales at the Gdansk assembly in 2010, with a true argument "that it was for professionals of a certain age with "great knowledge" that they find difficult to edit with the editor "wiki" (but in fact I was ashamed to tell him that I also wanted him to correct my bad spelling in Catalan, I was born in 1945)." He said it would be in 2012, and although a movie has been delayed. is already in a fairly operational beta stage.

Personally, the most important thing is that "combined with the Firefox checker"allows you to read/edit the article and fix ("wysiwyg") spelling errors.. (at the moment you can correct the apostrophes and plural see lining (nautical)..com remains.).

Wikimedia has another "wysiwyg" editor that also together with the Firefox checker makes it even easier to correct errors than using the native "wikitext" editor (it has more commands).. -see this editor)

Whooh!... since I see that those who were present at the Gdansk assembly (wikimania-2010) didn't say anything about it, I transcribe my speech (and arguments) with Jim Wales, to which he replied by saying that I had convinced him:

Hi Jim, congratulations for "wikitext",  you have achieved a great language much easier to learn to edit than the cumbersome "hypertext", but today there are plenty of "wysiwyg" editors for "hypertext" and none for "wikitext", that non existence represents its main drawback to be used by "full of knowledge" lawyers, architects, writers of my generation unable to become..ever.. "skilled wikitext editors".. , nevertheless they are able to edit  with "wysiwyg" editors like "word", etc..Back in 1987 I saw at Macworld-Boston (as a member of Apple Spain) the presentation of "Hypercard" wich gave birth a bit later to the "Berners-Lee hypertext", very complicated and difficult to edit (impossible for non professionals..) but boom!, the 20 following years gave birth to hundreds of "wysiwyg" editors for "hypertext", making it usable by everybody professional or not not..That's what Wikipedia needs, a "wysiwyg" editor able to be used not only by newcomers (a newcomer arrives to be a skilled editor in a couple of weeks..) but by anyone else specially the "professionals of a certain age with great knowledge" I've mentioned before, that will end their editing days without becoming "skilled wikitext editors"...

Jimbo answer: so we are losing a big amount of "full of knowledge" lawyers, architects, writers, etc.. that will never be.. "skilled wikitext editors".. don't worry ..we will have a "visual editor" in two years time..by 2012.


The testimony of my speech that he answered in English, but then in the hall in front of the Jimbo spoke to me in perfect Catalan, he was the representative of the Israel wiki, and he told me that he was descended from xuetes and that he had learned it in Tel Aviv with a girl from Palma who taught them, sheltering them, after 500 years!!

I made an article THE SONG OF BIRDS vs. Yiddishe Mamme - The Blind Cow (histo.cat)

My 14.000 articles in ca.wiki

https://ca.wikipedia.org/wiki/Usuari:Mcapdevila/!/page0

_________________________________________________

Stop Translating Template Parameters in Wikimedia Projects

In several Wikipediae there has been a phenomenon over the years that has generated a large amount of duplicate work and a loss of interoperability: the translation of template parameters, especially references, which give credibility to wikipedia

Some communities have created local versions of existing templates, translated parameter names, and in some cases simultaneously maintained both local and original English parameters.

This, in itself, already complicates maintenance. But the problem becomes much more serious when:

• Some administrators insist on running bots that automatically "retranslate" the parameters into their local language, even when the template already accepts the parameters in English,

• references and technical fields are also translated, which breaks compatibility with other wikis,

• and, above all, it makes it impossible to copy and paste templates from one wiki to another, because the parameters do not match.

This particularly affects:

• importing templates from enwiki, dewiki or frwiki,

• the reuse of shared Lua modules,

• the ability to maintain up-to-date templates,

• and the work of editors working on more than one project.

In short: parameter translation turns the code into an incompatible local dialect, and this goes against the basic principles of computing and the overall functioning of Wikimedia.

For this reason, I present the following proposal —in English, for international circulation— with the aim of preventing this problem from continuing to grow and recovering interoperability between projects.

 

Proposal: Stop Translating Template Parameters in Wikimedia Projects

1. Summary

This proposal recommends that Wikimedia projects stop translating template parameters and instead keep them in their original language (usually English), while translating only the documentation. Templates are code, and code syntax should not be localized.

2. Rationale

2.1. Technical syntax should never be translated

In computing, the syntax of a language—function names, parameters, keywords, API calls—is never localized. Only documentation is translated.

This is true for:

• Python

• C

• Java

• HTML

• Lua

• SQL

• CSS

Translating syntax breaks interoperability.

2.2. Translated parameters create incompatibility between wikis

When a template uses:

• |name= in English Wikipedia

• |nom= in Catalan Wikipedia

• |nombre= in Spanish Wikipedia

then:

• templates cannot be copied between wikis

• improvements cannot be shared

• examples from documentation do not work

• newcomers cannot follow tutorials

• modules and templates diverge over time

This fragmentation is unnecessary and harmful.

2.3. Translation multiplies maintenance work

Every translated parameter becomes:

• an extra alias to maintain

• a potential source of bugs

• a divergence from upstream templates

• a barrier for cross‑wiki collaboration

It creates work without creating value.

2.4. It contradicts global computing standards

If programming languages had followed the same logic, we would have:

• SI (x > 3) ALORS in French

• SI (x > 3) ENTONCES in Spanish

• IF (x > 3) in English

The global software ecosystem would be impossible.

Templates are code. Therefore, template syntax should not be translated.

3. Benefits of keeping parameters unlocalized

.Interoperability across all Wikimedia projects

Templates can be copied, shared and improved globally.

.Lower maintenance cost

One set of parameters instead of many.

.Fewer errors

Translated parameters are a major source of confusion.

.Better onboarding for newcomers

They can follow tutorials, documentation and examples from any wiki.

.Alignment with industry standards

Wikimedia should follow the same principles that make global software possible.

4. Concrete proposal

1. Stop translating template parameters in new templates.

2. Keep parameters in their original language (usually English).

3. Translate documentation, not syntax.

4. Gradually migrate existing templates toward unlocalized parameters.

5. Keep translated parameters only as optional aliases, not as the primary interface.

5. Example

. Localized syntax (current practice)

CĂłdigo

{{Infotaula persona
 | nom = ...
 | data_naixement = ...
 | lloc_naixement = ...
}}

.Standardized syntax (recommended)

CĂłdigo

{{Infobox person
 | name = ...
 | birth_date = ...
 | birth_place = ...
}}

Documentation can remain fully translated, but the code should not be.

6. Conclusion

Template parameters are code. Code should not be translated. Only information/documentation should be localized.

Adopting this principle will make Wikimedia projects more interoperable, more efficient, and more aligned with global technical standards.