[go: up one dir, main page]

Jump to content

Community Wishlist Survey 2021/Translation/Templates translation

From Meta, a Wikimedia project coordination wiki

Templates translation

  • Problem: Some templates in different wikis have similar functionality, but it's unnecessarily difficult and time-consuming to copy them from one wiki to another.
  • Who would benefit: Volunteers who edit in more than one wiki and who copy, adapt, and translate information from one wiki to another.
  • Proposed solution: mw:Multilingual Templates and Modules work can be aid by task T243150, which will give users a tool (js-script maybe) which will do what Extension:ContentTranslation already can - translate templates.
  • More comments: There need to be some json on Commons or other way for users to translate parameters of templates and templates names. For citation templates there would be great if there would be possibility to implement some logic, like ru_author = en_last1 .. ", " .. en_first1 etc.
  • Phabricator tickets: task T243150 task T238417
  • Proposer: Carn (talk) 11:19, 18 November 2020 (UTC)[reply]

Discussion

  • Amire80! Carn (talk) 11:24, 18 November 2020 (UTC)[reply]
  • A very, very, long-desired wish - if it can be done in a fashion that somehow avoids disrupting the larger local communities by bulking out the templates themselves or the lists of templates that would be a positive. While Abstract will eventually get round to some form of this, because it's a smaller component of their overarching plan, a more tailored project might be more beneficial Nosebagbear (talk) 15:13, 18 November 2020 (UTC)[reply]
  • This is very much in the high cost/high benefit category—it seems like a daunting task, but the savings in duplicated editor effort will make it worth it. I'm not sure if the community wishlist team would be able to take it on, though. {{u|Sdkb}}talk 02:57, 19 November 2020 (UTC)[reply]
    I updated a task, I think we can eat elephant part by part. Articles are not always translated entirely. Sometimes it is necessary to translate a single section, and it is convenient to do this by copying the wikitext. At the same time, templates are often found in wikitext on local languages. And it's good if these are english templates, there are often local analogues for them. In some wikis cite web analogues has "URL" and not "url" parameter name. Replacing template names and parameters can be automated.
    If users will have opportunity to insert analogs of parameter names themselves (I don’t know how best to do this, via wikidata or by filling in json tables), then data will be collected that can be used in the future directly for global templates. Carn (talk) 13:24, 19 November 2020 (UTC)[reply]
  • Complete infrastructure standardization/unification would be GREAT. And IMHO the EN wikipedia has the most complete and good standard. Making a scalable version of template (basic, rich, full) maybe a good solution for translations or for smaller audiences or countries. But using the SAME template could help a LOT the work of a global wikipedia. This is a standard in every kind of structured and collaborative work :) --Wikit2006 (talk) 22:06, 22 November 2020 (UTC)[reply]
  • See the big section I added after the "Discussion" section. If User:Carn agrees to these ideas, I recommend rephrasing the top as follows:
    • "Problem: Small or new wikis don't have template infrastructure. Old versions of templates that they copy from big wikis are not updated properly." -> This should be changed. This problem is very real and important, but the truly complete solution for this is doing the whole Global templates proposal, which is probably too big for the Community Tech team. It should be done, but at this stage, I recommend addressing a different, smaller problem: "Some templates in different wikis have similar functionality, but it's unnecessarily difficult and time-consuming to copy them from one wiki to another."
    • "Who would benefit: Volunteers editing templates and modules and users of small wikis." -> I recommend changing it to "Who would benefit: Volunteers who edit in more than one wiki and who copy, adapt, and translate information from one wiki to another."
    • The current proposal at the top says: "There need to be some json on Commons or other way for users to translate parameters of templates and templates names". In the big section I added, I explain my current proposal for how this will work. Very briefly, I recommend not changing anything at this point, but simply reuse the current algorithm in Content Translation, which is based on TemplateData, and making it available to more users. --Amir E. Aharoni (talk) 13:39, 26 November 2020 (UTC)[reply]
Admin from SqWiki here. Truth is small Wikis (like we are) rely mostly on EnWiki for everything. Most of our new articles come from CTT from EnWiki. Same is also true for technical things like templates, etc. In most cases, the workflow used to "create" a new template by a user is this: Starts to write something translating from EnWiki. -> Realizes a certain template is missing in SqWiki. -> Copy-pastes the template from EnWiki, importing it, usually without translating its components. -> Saves it as a template with the same name as in EnWiki, without a doc subpage and continues working on the page it was working with when the "template inconvenience" presented itself. 90% of our templates are with English names and without explanatory subpages (documentation) because of this process. They are not even connected on Wikidata, because people don't bother to do so. Actually that's where the untranslated title comes into help because you can search for it on EnWiki to read its documentation if you want to change something (and hopefully connect them on Wikidata). So anything that helps facilitate template importation and, hopefully, change the aforementioned workflow, is a very good thing to have. - Klein Muçi (talk) 12:01, 27 November 2020 (UTC)[reply]

This is on the roadmap of the Language engineering team.--Snaevar (talk) 14:45, 21 December 2020 (UTC)[reply]

Practical suggestion: refactor CX template adaptation

Taking a deep breath...

OK, so I'm in a strange conflict of interest here: I'm writing this as User:Amire80, a volunteer editor in several wikis, but I should mention that I'm also User:Aaharoni-WMF, a staff member of the Wikimedia Foundation, in the team that develops Content Translation, which is related to this project. I'm also the author of mw:Global templates and most of its subpages. With these disclaimers out of the way:

Global templates were already proposed in the Community wishlist in 2015, and came in at #3. On the results page it's listed as "in development", but it wasn't actually developed: it was, understandably, too big for the Community tech team, and it somehow slipped from the Parsing team plans, too. However, the wish is very much alive, and lots of people still think it's necessary (one example). So what can be done by the Community Tech team as a reasonable step towards making this come true?

The appropriate thing to do about templates translation in the context of Community Tech is to implement my suggestion in https://phabricator.wikimedia.org/T243150: build a Template adaptation service and the frontend for this service. Here's how it will work:

  1. Refactor the part of cxserver that adapts templates in Content Translation, so that it would be usable not just in Content Translation, but also in the wiki syntax editor and in Visual editor. (cxserver is a simple backend Node.js service that works together with Content Translation. One of its functions is template adaptation.)
  2. The technology for mapping template titles and parameter names doesn't change at this stage, and remains the same as in Content Translation / cxserver. The algorithm is as follows:
    1. If the template page in the source wiki is not linked to anything in the target wiki through a Wikidata sitelink, fail: "This template is not associated with any template in the target wiki".
    2. If the template page in the source wiki is linked to a template in the target wiki through a Wikidata sitelink, use the title of the target template for adaptation.
    3. Check whether the target template has TemplateData defined. If not, fail: "The target wiki does not have TemplateData".
    4. Check each parameter name in the transclusion and search for it in the target template's TemplateData:
      1. If there is a parameter with the same name, use it.
      2. If there is no parameter with the same name, but there is a parameter with the same alias, use the main name of that parameter.
      3. If nothing could be found in the previous two points, fail: "Parameter $1 couldn't be found in the target wiki" (replace $1 with the parameter name).
    5. The parameter values are copied as-is. Auto-adapting parameter values can be added in the future, but it's not a part of this proposal.
  3. There will be no functional change for end-users of Content Translation. The code from cxserver will be moved to a separate service, and Content Translation will just switch to using that service for template adaptation.
  4. Global template wiki syntax adaptation tool frontend, with empty fields
    Global template wiki syntax adaptation tool frontend, with input and output
    When editing in the 2010 wikitext editor, people will have a new button: "Adapt a template". This button will allow the following (see the mockups):
    1. The editor copies the wikitext of a template transclusion in another wiki. For example, a transclusion of {{Cite encyclopedia}}.
    2. The editor clicks the "Adapt a template" button in the toolbar. Clicking the button shows a dialog box. This dialog box has a selector for the source wiki, and two text fields: Source template and Target template. The "Source template" is editable, the Target template field is read-only.
    3. The editor selects the source wiki in the wiki selector, for example "English Wikipedia". The target wiki is the current wiki, in which the page is being edited.
    4. The editor pastes the template source to the top box.
    5. The box queries the template adaptation service.
    6. If the adaptation worked, the adapted template output is shown in the Target template field.
    7. If the adaptation failed, the reason for the failure is shown (see the "fail" points in the adaptation algorithm above).
  5. When editing on mobile devices, a similar dialog can be shown.
  6. When editing in Visual Editor, the template can be simply copied from one wiki and pasted in another. This will work similarly to copying and pasting wikitext and converting it to rendered HTML on the fly. When copying, the source wiki name will be stored in the clipboard. When pasting, VE will query the template adaptation service and try to adapt the template. If it fails, VE will show the reason.
  7. When editing in the 2017 wikitext editor, it will work similarly to VE, and the "Adapt a template" button can be available, too.

Why do I believe that it's a good task for Community Tech?

  • It's relatively small.
  • It doesn't change any deep algorithms, and only gives editors more convenient access to already-existing technologies.
  • It fits together well with existing editing tools, and once it's deployed it simply becomes a part of the editing workflow.
  • It adds a tool that is not specifically about languages and translation, but also about any cross-wiki activity. For example, copying a template transclusion from English Wikisource to the English Wikipedia is sometimes needed.
  • It's somewhat comparable to the TemplateWizard extension, on which the Community Tech team already worked in the past.
Template adaptation service flowchart. This proposal deals only with the API entry point, the gray process boxes, and the green result box. The blue boxes will be in a future project, but this project here is supposed to be forward-compatible with it.

Why develop it now? Why not wait for the start of the work on the Global templates repository? It's not certain when will the work on the Global templates repository begin, or whether it will begin at all. Whenever this happens, it will be a very large project. On the other hand, the template adaptation service proposed here is a much smaller project, and it will be immediately useful to editors in all editing interfaces: wikitext 2010, wikitext 2017, mobile, Visual editor, and Content translation.

Where does it fit in the bigger Global templates roadmap? If and when the full-fledged Global templates repository will become available, such a service will be needed. If this project is done, then it will already be mostly available! The service's API will remain the same, and using the global repository instead of local TemplateData will become a new branch in the algorithm. (See the attached flowchart.) All the client editors probably won't need any modification.

I hope it's useful. Other comments are welcome. --Amir E. Aharoni (talk) 13:29, 26 November 2020 (UTC)[reply]

@Amire80 - there is d:Wikidata:Property proposal/Wikipedia infobox field active now, and some broadside view would be helpful. Such properties of templates will allow us to see (preferably, of course, in automatic mode) which templates are most ready for transfer to a centralized repository.

If the data is stored in the form of tables on commons, then the tool for working with such a table (script in the browser), together with the tool for using such a table for translation (button in the text editor) will help the community. If now there are some options for centralized storage of templatedata, we must immediately link this solution with it. At least I'm talking about the data storage format. It is not our job to create more unnecessary duplication in an attempt to combat unnecessary duplication. Carn (talk) 09:59, 6 December 2020 (UTC)[reply]

The reason for delveoping it now is that it's needed now. I don't underant why its such as major problem, tho it might be if implemented at once for all languages. DGG (talk) 10:27, 29 November 2020 (UTC)[reply]

  • @Amire80: If defining new variables in templates was possible, wouldn't this be just the matter of mapping $english_variable:={{{localized_parameter_name}}} and calling the en.wiki template within a localized wrapper template? Also, with local template variables some nested template code would be much more comprehensible. Ponor (talk) 08:19, 3 December 2020 (UTC)[reply]
    This assumes that English templates are some kind of a "main" version, which is tempting, but wrong. English is, indeed, the main source for translation for many languages, but not for all. Some wikis use other languages as the source for translating content or importing tools: Spanish, French, Russian, German, Polish, Indonesian, Chinese, and so on. In addition, "just [...] calling the en.wiki template" sounds easy, but actually it's quite difficult: Evidently, software developers have attempted to implement cross-wiki transclusion since 2004, and never managed to complete it. It will certainly be done some day, but it will have to be done in baby steps.
    More generally, the $english_variable:={{{localized_parameter_name}}} syntax you are proposing may be good, but it's new. Any new syntax will require much more development resources from the engineers, and much more adaptation effort from the template maintainers on the wikis. What I propose here doesn't add any new syntax, but uses the existing wiki markup and TemplateData. Even the adaptation algorithm that I propose is already implemented in the code of cxserver, and I only propose to refactor it so that it would be directly usable from all versions of the wiki syntax editor and the Visual editor (currently it's only usable from Content Translation).
    The smaller a project is, the likelier it is that it will actually be implemented and deployed. And later it can be extended :) --Amir E. Aharoni (talk) 08:36, 3 December 2020 (UTC)[reply]

Voting