Extension talk:Translate

Archive.

---

Previous page history was archived for backup purposes at Extension talk:Translate/LQT Archive 1 on 2015-07-10.

Since English is not good is the question of the automatic translation.

*1.Translated the original text

*2.Fixed only settles the original text

*3.In page translated " mark for translation "

*4.By FuzzyBot, translation of all of the paragraph is overwritten in the original .

I want to leave as it is a translation .

I'll be if I do? --~~~~

Section "Changing the source text" from Help:Extension:Translate/Page_translation_administration page state:

Unused unit translations are not deleted automatically, but that should not cause trouble.

It's ok. But unused messages is along count into the info value percentual about state of translated page and it is confusing.

Is usable call of the function MessageGroupStats::clearGroup() for remove unused translation units? Or exists another method for it?

By 'unused messages' do you mean for example T:201 T:202 of the following snippet ? (from https://www.mediawiki.org/wiki/Manual:HTMLForm_Tutorial_3). These comments correspond to previous translated sections which have been corrected such as NO longer to be translated now. Advice in the translation rules was to keep the tags. These comments do not appear on the page but if they generate erroneous statistics we can decide in a first step to remove them (?) carefully from the source (non excluding the developpement part of ignoring them for statistics - but this will be a Phabricator task).

<translate>
<!--T:157-->
Select multiple users.....
</translate>
<source lang="php">
$formDescriptor = [...
</source>

== url== <!--T:201-->

<!--T:202-->
[[File:HTMLForm Url.jpg|500px]]

<translate>
<!--T:158-->
Textbox....
</translate>

... let we still read other points of view.

Christian Wia (talk) 07:23, 1 August 2019 (UTC)

No. I specifically meant translation units 51 and 52 from page Help:Signatures (Special:Diff/3339237/3338935). After reverting changes and re-mark page to translate for some time, it still showed that only 95 percent of translation units were translated. It seems to have been just some cache, because now it's ok. But still interest me, what method I can use to get a list of currently id's of the translation units from the page what use by the current revision.

On lower (ex. 1024x768) resolutions (or when there's a lot of text) the $parameter buttons obstructs the bottom part of the edit box - they cover part of the text, and don't allow to set position of the cursor by clicking. Please move it outside of the edit field (ex. below it).

https://postimg.cc/gL8VLsyK

Placing below into your user skin css do that:

.grid .tux-editor-actions-block .tux-editor-insert-buttons{
 position: initial;
}

Do you happen to use Firefox 88? There’s a ticket about this issue in Firefox 87–88, but older and newer versions (including Firefox 89, released as stable two days ago) have been reported to be unaffected. If you have the same issue, simply updating Firefox (hamburger menu → Help → About Firefox) should fix it.

Yes, I was using FF 88. After update the edit field expands correctly.

By the way, I noticed that the $param buttons shows after the documentation loads in the right panel (it can sometimes take a few seconds). If they are not connected (but they probably are), then maybe display those buttons before starting to load the doc?

They’re connected, the so-called “insertables” ($param buttons) are also computed on server-side, and loaded in the same HTTP request as the documentation (for the message on your screenshot, it’s https://www.mediawiki.org/w/api.php?action=translationaids&format=json&title=Translations:Help:Magic_words/8/pl). Although I don’t know whether they’re actually interconnected on the server side, or would it be possible to split up the API action.

Tracked in Phabricator
Task T204076

When we use the <language> tag, it will show in the page but how to make it show in the sidebar menu ?

That’s tracked in T204076, which is blocked on T287075.

No, it’s not blocked. This feature has been ready for years; it’s blocked only on Wikimedia sites because of our interwiki language links. Third-party wikis (like translatewiki.net) can already use it by setting $wgPageTranslationLanguageList to 'sidebar-only', 'sidebar-fallback' or 'sidebar-always'.

There's something that has bothered me for a long time, and only now I am finally speaking up.

There's a recommendation to put {{#translation:}} at the end of categories on translatable pages. It was defined as a "recommendation" by Nemo in 2015.

I more or less understand the rationale for this: if you don't use this syntax, all the translated pages end up in the same category, making the category listing long, repetitive, and hard to use.

But it also has some problems:

• The category for each language has to be created separately and manually.
  • If this is not done, there are a lot of non-existent ("red") categories.
• The [[Category:Name{{#translation:}}]] syntax is kind of ugly and not self-explanatory.
• Ugly or not, it has to be added to every translatable page, overloading it with yet more wiki syntax, in addition to <languages />, <translate>, <tvar>, etc. (I mean, technically, it doesn't have to be added there, but since it's recommended, people who want to follow the recommendation do it on a lot of pages.)

I realize that it will probably require some development, but could it become simpler?

The simplest thing I can think of is that categories would show just the original page and not the translations. Or, if I'm missing some issues with this, maybe the translated categories could be auto-created.

Are there any other thoughts?

@Kaganer, @Nikerabbit, @Shirayuki, I'd like to hear your opinions.

For example, Category:WMF Projects 2022q1 and friends do not have translation pages.

If there are many pages, it would be useful to filter by language (in my case, Japanese and English). Some languages may have more than one fallback language.

As one of the translation administrators, I like the current spec because I can see how many pages of a particular language are in a category.

Yeah, but wouldn't it be more convenient if they were at least created automatically?

And wouldn't it be better if instead of using categories, you could see a proper statistics page to see how many pages of a particular language are in a category?

Categories (primarly) - is very useful and comfortable navigational way. Not for translate admins - for readers. Many people do not have the experience or the habit of reading in foreign languages. And they need not just a clear entry point, but a way to see "what else is useful in my language?"

The fact that the categories mechanism did not fall apart in any way (and was, in fact, ignored in the mobile application for years) is a big mistake.

There are many problems with categories, and not only related to translatable pages. For example, the fact that it is almost 20 years since they cannot be made multilingual (writing and displaying). This is the Great Birth Trauma of Wikimedia Commons.

But if you do not make revolutions (although I am for it, as I should be, given my origin), then I would suggest this approach:

1. Eliminate the need to use in category descriptions (but leave it as a possible option, for backwards compatibility)
2. If the translatable page is included in a category that is also marked for translation, then the bot should automatically...
   1. ...add language suffix for category name in a subpages with translations
   2. ...create language subcategories for each of the subpages that appear (if they don't already exist)

This task may be performed with the processing operation (re)marking new version for translation.

Is there a setting to hide translated pages from non-translators until they are 100% reviewed? I'd like to have all pages reviewed by at least one other person before going "live".

Pardon if I'm missing something obvious, I scrubbed through the various help pages and couldn't find anything indicating that it's a feature.

I don’t think it’s currently possible, and while it seems reasonable at first sight, there are some potential issue with it:

• What does “hide” mean? Since translations are wiki pages, you can’t really make them entirely disappear for “non-translators” but still appear for translators (the page either exists or doesn’t exist). It could be hidden from the language selector (and there’s precedent for that: a similar but not configurable hiding was recently removed in phab:T359974) – is this what you mean?
• What if a page used to be 100% reviewed, but is no longer? For example because someone edited a translation (maybe just a typo fix), or because the source page changed (which could even be a complete rewrite). Should the page disappear? The answer is probably “it depends”, which is not necessarily something that can be implemented in the program code. (And even if the answer is a definite no, that complicates things quite a bit compared to a definite yes, as it’s not enough to track the current state, the historical state needs to be tracked too.)

Thanks for the reply.

• Yes, hiding it from the language selector is what I meant.
• If the source page is updated, it would be put in the untranslated queue as normal and the existing translated pages would still be considered 100% reviewed since all the actual translations so far are reviewed. I believe this is how it's treated currently (I just tried it). But yes, that's a good point about the consequence of making a whole page hidden just because a translator made an update to their translation or translated a newly added source section.

I suppose the best implementation would be

1. In the case of the initial translation of a page, hide the page from the language selector until there's at least one reviewed piece of content on the translated page.
2. If a translation is updated or a new translated section added, show the old state of the section until the new one is reviewed. But you're right that it'd be much more complicated on the backend.

Anyway at this point, I suppose it's a pipedream feature request since it sounds like there's not really a system in place currently and it's beyond my skills to add. I appreciate the brainstorming/idea exercise nonetheless :)

I use the Translate extension very often, but many messages are hard to be translated because of the lack of syntax highlighting (like in Extension:CodeMirror). Could syntax highlighting be integrated in the Translate extension?

I find syntax highlighting useful on pages with heavyweight syntax like large commented-out blocks, templates and magic words embedded at multiple levels or many HTML/XML tags. None of these should normally happen in translation units (complex syntax should be either outside of the translation unit or within <tvar>s). If a particular message has heavy syntax, you can always click on Show in wiki editor and use syntax highlighting there. I’m not strictly against highlighting on Special:Translate, but I don’t see much point in it, and if it does happen, I’d like it to be separately toggleable from the regular editor.

Pages like this or this are very syntax-heavy and it is hard to identify the text that has to be translated. The same happens sometimes on Translatewiki.

Those are both good examples of what @Tacsipacsi is saying – the pages have been inappropriately marked up for translation with very large units that are hard to translate. This is less a problem with Translate as a tool, and more a problem with the way the tool is being used.

Hello, I wanted to make a small layout edit (link in bold text) to c:Template:Global maintenance category but it doesn't work. Since there is no "/layout" subpage I did my edit on the "/i18n" subpage, but it doesn't work. Strangly my edit some times before on the same subpage was working. Does someone has an idea why? Is this a cache problem or has it sthg to do with /i18n? And I also can't change/edit the layout of "/i18n/en". It is just stated

This page cannot be updated manually. This page is a translation of the page Template:Global maintenance category/i18n and the translation can be updated using the translation tool.

Thx a lot already and best Regards!

Actually now it works, maybe a Cache problem!? But still strange for me, that I was not able to edit /i18n/en, but I am also not so experianced in i18n affairs, hmmm.

Help:Extension:Translate/Page translation example has an example how the process works. It's not a cache problem.

Thank you Nikerabbit! But this link is too general and says nothing about what is i18n. My focus is less in translating instead more in layout matters: How to change the layout of a tranlated page/template with these subpages.

• Sometimes there is an /i18n/layout subpage, which is editable, here not
• Here is an /i18n page what is editable
• The subpage /i18n/en offers "edit" too on the tabs and it is possible to see the code, but then a message box as mentioned above appears.
• For an other subpage like /i18n/de it offers only "tranlate" and no code is visible.

Do you understand or someone else has an answer or knows a more specific help page for that? So what the hell is i18n? :) Even on c:Commons:Localization nothing. Thx already!

Language code subpages of translatable pages (like /en, /de, etc.) are not directly editable and they are managed by the Translate extension.

Ok nikerabbit, that seems to be right for /i18n/en etc. but simple /en subpages (e.g. C:Template:Template category/en) are editable. Thats why I asking for this nowhere-explained-i18n-subpage-structure what seems to make a kind of difference!? Regards

Those aren't part of translatable pages. You can usually identify translatable pages by the "Other languages:" section at the top with blue circles.

I found in Manual:$wgPageLanguageUseDB that we forgot the second line:

$wgPageLanguageUseDB = true;

$wgGroupPermissions['sysop']['pagelang'] = true;

I just saw in this topic below (https://www.mediawiki.org/wiki/Topic:Xlczwiqmyio6ymei) that it's possible to set different content languages for source pages,but I think I need further instructions.
So I have to add $wgPageLanguageUseDB = true; to LocalSettings.php, but how then do I mark the content language of a page?

And does that mean anyone can create a page in any language on my wiki? Is that a good idea, or are there downsides? We have 10 active languages and I guess the ability to create a page in a different language than English would encourage more people to create content.
The downside I see: If e.g. the page is created in Japanese than every translator needs to know Japanese to translate the page in any language, or can they still translate from the English translation somehow? Also information will have to be added in the Japanese version of the page first then, right? Or can I e.g. switch the content language without losing the text in any language?

There is a link in the sidebar to page information where you can find link to change the language. You can also go to Special:PageLanguage directly.

The correct language must be set before page is marked for translation and cannot be changed later.

There is currently no first class support for translating through a middle language, but translators can emulate that by ensuring that English appears in their assistant languages.

Hey, thank you, but somehow this doesn't work yet. We've added $wgPageLanguageUseDB = true; to LocalSettings.php but nothing happened. I can't access Special:PageLanguage or find the link in the page information page. Is there something else we need to configure first?

That is a MediaWiki core feature, so I am not familiar with debugging that. What version of MediaWiki are you using?

Is there a way that you could add functionality for it to run a page cache purge (?action=purge) after saving a translation? I ran into issues on a private wiki where the list of available languages for a page wouldn't update when adding a new language until the page cache was purged.

This should work correctly out of the box. Is your job queue configured correctly?

Jobs run and the queue is currently empty when I try and run runJobs.php. Is there something special that needs to be setup for Translate?

@Nikerabbit: I see nothing in RenderTranslationPageJob.php that would invalidate the parser cache for other languages when rendering a translation. If the code is not there, where is it?

There is a purge call in \MediaWiki\Extension\Translate\PageTranslation\Hooks::updateTranslationPage