Extension talk:Translate

Archive.

---

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

I want to display the translated page name in other page.

If I understand translated title is not in page content but available by API with api.php?action=parse&page=Page_Title/fr&prop=displaytitle

But I'll use a hack of DPL3 to find the translated name of a page with PHP. Skins has access to it thanks to Skin.php with `$out->getPageTitle();` but I don't think that extensions like DPL have access to the "output".

So can I access the translated title from another extension?

Hello,

One way you could do this in another extension involves using the \MediaWiki\Extension\Translate\PageTranslation\TranslatablePage class in the Translate extension:

use MediaWiki\Extension\Translate\PageTranslation\TranslatablePage;
// Main Page Translate is the title of the translatable page
$tp = TranslatablePage::newFromTitle( \Title::newFromText( 'Main Page Translate' ) );
// fr is the French language code
$tp->getPageDisplayTitle( 'fr' );

Regards,

Abijeet Patro

I have a page /site/index.php?title=Example

I translated its contents into German including the title.

I can access the localized page via /site/index.php?title=Example/de but not /site/index.php?title=Beispiel

Is there any way to do this?

No, because nothing prevents you from translating two titles in the same way, which would cause a conflict. See also phab:T301052.

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.

Please add the instructons to install: {{ExtensionInstall |repo-name=Translate |registration=required }}

There are instructions in https://www.mediawiki.org/wiki/MediaWiki_Language_Extension_Bundle#Installation already.

hi,

I'm working on an internal MediaWIki website, in which multi-languages would be implement in next phase, so is there any reference MW website already implement extension:Translate?

For example this one? I don’t know what you mean by “reference website”, but there are quite a number of translatable pages—including this very one…

And Extension:Translate#Prominent users of the Translate extension.

You can see the others MW website that used Translate extension from Wikiapiary -> https://wikiapiary.com/wiki/Extension:Translate

Thanks. @Lamjon

Instead of let system auto generate the Marker like <!--T:1--> in article, can we modify/control an article to have one or two markers since I already have the tranlation text for some of the languages ?

Yes, if you already had the same translation unit on the same page, you can (and, in order not to waste translators’ time, should) reuse them by manually adding the appropriate translation unit numbers using the same format the software would add them; it will pick them up. However, beware that if a translation unit was not present in the previous version marked for translation, the translations won’t be marked outdated if you change the unit compared to how it last appeared in translation. Also, it works only if the translation was on the same page, and using Translate; manual translations can’t be imported this way.

Appreciate that you can explain the steps manually adding the appropriate translation unit numbers .

Simply add them before marking the page for translation, using the same format the system uses.

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'.

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.

Has anyone built a bot to pull sections from the translate wizard, pass them off to some translation service, and post them back again in order to perform mass initial translations?

I find myself just accepting the suggestions on Special:PagePreparation all the time. Is there any bot or existing piece of automation that can simply add the markup on all / bulk pages?

Not that I know.