View source for Thread:Support/ Wp/trv Translation of MediaWiki (most important messages)/reply (2)

Problems? Questions? Suggestions? Write your message below. – See also the FAQ or try to catch us in IRC.

Your request has been forgotten? Feel free to post a reply to bump the thread to the top. The thread summarization feature is broken, see Phab:T245109. Very old threads have been archived.

This message to be translated does indicates that the question mark must be encoded, but it does not explicit which form should be used.

In my opinion, we should not have to reencode the URL in the application and should be able to post the exact URL as it works, it should be up to the application to reencode it if it wants to encapsulate it into another URL or document format (other wise the result for any URL is unpredictable, notably for other characters like %, <, >, &, #

Note that a non-encoded URL may contain a fragment identifier, but if the URL has to be encapsulated into another URL for example in a query string parameter, that hash character will also need to be encoded, and all percent characters; whitespaces may also be present in non-encoded wiki page titles, and are normally reencoded in the URL form, but the default in browsers is to rencode them as +, whilst MediaWiki reencodes them as _ for page titles. Mediawiki also has special handling for + or ? and some other punctuations, allowed in page titles, that also need to be encoded for URLs, to avoid their interpretation as whitespaces remapped to '_' or as a question string delimiter. For URLs to some "Special:" pages there are other restrictions or different behavior for whitespaces.

So at least first explicit how to encode the question mark; but in fine please change the application's code to handle itself any needed reencoding, so that we won't ever need any such manual unpredictable tweak; in that later case, drop this statement from the message.

Note that there are various messages asking to the final users (reading these translated messages) to use an escaped form for some parameters or values to provide in the final app. This is generally not clear when there's no link to explin how to safely escape these parameters, and as well this exposes server-side or client-side security issues, or unexpected side-effects (which may be desastrous, either for theses users themselves, or site-wide or application-wide for all their users): those messages should be updated to reflect a change in the code of Mediawiki or its extensions: it's up to these applications to handle the proper escaping. Translators should not bothezr about this internal technical trick.

• Wikimedia:Pageviews-url-structure-massviews-target/en
• Wikimedia:Pageviews-url-structure-user/en

The links inside the message to translate do not seem to resolve on any known wiki (not in Mediawiki wiki, and not on Meta-Wiki) so that the documentation page can be effectively seen ?

• MediaWiki:Wikimediaapiportaloauth-page-introduction/en
• MediaWiki:Wikimediaapiportaloauth-ui-client-field-callback-uri-help/en

It's not clear which wiki hosts this API documentation. Shouldn't it point to a known wiki, or use a stable URL (possibly hidden in a "tvar", including a possible "Special:MyLanguage/" if supported by the target wiki)?

Note that most wikis will support a Wikimedia API special page, but will not necessarily host the documentation that will be centralized, maintained and translated elsewhere, on another wiki.

Can someone block User:Obsuser? He's edit warring, behaves stubbornly, does not respect the agreements made between Serbian translators regarding translations, and translates too literally. For example, the changes he has made in this edit only make it difficult to understand the text. He translated "Intended blockee" as "Намењено да се блокира" (Intended to block) -- which is very unclear in general, let alone in the Serbian standard language. The previous translation was "Блокирани корисник" (Blocked user) -- which was a very natural option. Due to the same pattern of behavior, he was blocked on Serbian Wikipedia permanently more than a year ago. User:Kizule can confirm this since his mother tongue is also Serbian. Thanks in advance!

I can confirm all things which BadDog said. He (Obsuser) still doesn't understand what teamwork means.

Bump. He is like an "energy vampire" who works only on his own and consumes the energy of us who are trying to contribute.

He persistently wants to translate literally, on incomprehensible way.

And, my god, without consulting with someone else.

I only see one recent thread on their talk page. Was it about this topic?

Partially. But neither the first nor the last, for sure.

I created phab:T269469 on 2020-12-04 to request setup of a project for translating the new https://meta.wikimedia.org/wiki/Toolhub software project.

I'd like to rename the head of Krinkle/intuition-web and mw-tool-orphantalk to "main".

Is that supported currently? What should I do? Anything I can help with?

In my own utility scripts, I found that for most use cases it is possible to be agnostic of the branch name by using origin/HEAD in pulls or checkouts, but for pushes it probably needs to be specified somewhere.

Just need to explicitly name the branch in repoconfig.yaml. There are already a few examples using the name "main".

Thanks. Done at https://gerrit.wikimedia.org/r/c/translatewiki/+/649444/

As per phab:T270010, Ask for more information's link target points to Phabricator, while it in fact should point to GitHub to https://github.com/commons-app/apps-android-commons/issues . You can observe the issue here: [1]. Please fix and thanks in advance!

In the FAQ it says "If you spot a spelling or grammar error in the original English message, or you would like to suggest a better way of expressing the message, then please do not change the English message but instead put a message on the talk page of the project concerned." There is indeed a problem with six Mediawiki Core messages, but I'll be damned if I can find "the talk page of the project". Starting from the "Category:Supported projects" through "Category:Open support requests for MediaWiki", I end up here. So here it goes.

The six messages MediaWiki:Size-kilobytes/qqq, MediaWiki:Size-megabytes/qqq, MediaWiki:Size-gigabytes/qqq, MediaWiki:Size-terabytes/qqq, MediaWiki:Size-petabytes/qqq, and MediaWiki:Size-exabytes/qqq all describe the "Size (of a file, typically)" using the decimal (SI) prefix convention (e.g. exa = 1000×1000×1000×1000×1000×1000). However, in practice, the sizes displayed on various pages by all Wikimedia instances (such as Special:ListFiles in here) are all computed using binary prefixes (e.g. exbi = 1024×1024×1024×1024×1024×1024). It has been suggested a Phabricator ticket be created (how?) to get the developers to change the size-computing code; however, it would be much, much simpler to change the message names and qqq descriptions to match reality. Thus:

• MediaWiki:Size-kilobytes should become MediaWiki:Size-kibibytes and its qqq be amended accordingly
• MediaWiki:Size-megabytes should become MediaWiki:Size-mebibytes and its qqq be amended accordingly
• MediaWiki:Size-gigabytes should become MediaWiki:Size-gibibytes and its qqq be amended accordingly
• MediaWiki:Size-terabytes should become MediaWiki:Size-tebibytes and its qqq be amended accordingly
• MediaWiki:Size-petabytes should become MediaWiki:Size-pebibytes and its qqq be amended accordingly
• MediaWiki:Size-exabytes should become MediaWiki:Size-exbibytes and its qqq be amended accordingly

Addendum: More erroneous messages.

• MediaWiki:Size-zetabytes should become MediaWiki:Size-zebibytes and its qqq be amended accordingly (note the misspelling; it should have been zettabytes)
• MediaWiki:Size-yottabytes should become MediaWiki:Size-yobibytes and its qqq be amended accordingly

I strongly suspect the *pixel suite of messages also suffers from the above problem. I was unable to find example pages that use those messages. Any help would be appreciated. Note that the *pixel messages should be made plural for consistency's sake.

• MediaWiki:Size-kilopixel
• MediaWiki:Size-megapixel
• MediaWiki:Size-gigapixel
• MediaWiki:Size-terapixel
• MediaWiki:Size-petapixel
• MediaWiki:Size-exapixel
• MediaWiki:Size-zetapixel (note the misspelling)
• MediaWiki:Size-yottapixel

I hope this problem will be resolved once https://phabricator.wikimedia.org/T54687 goes in.

I hope this problem will be resolved once https://phabricator.wikimedia.org/T54687 goes in.

Bump. (To see if the previous edit will take once a further edit is made.) Edit: I think this a browser problem local to myself. Then again, maybe not.

There’s currently a cache problem with threads, you need to ?action=purge to see the updated thread.

Hello. While translating strings from MediaWiki, I found some of them that refer to the current user but are missing the $GENDER magic word (and they can't be translated to natural Spanish without it).

These are:

• MediaWiki:Notification-bs-pageassignments-user-group-add-summary/en
• MediaWiki:Notification-bs-pageassignments-user-group-add-subject/en
• MediaWiki:Notification-bs-pageassignments-user-group-add-body/en
• MediaWiki:Notification-bs-pageassignments-user-group-remove-summary/en
• MediaWiki:Notification-bs-pageassignments-user-group-remove-subject/en
• MediaWiki:Notification-bs-pageassignments-user-group-remove-body/en

There's also a mismatch between documentation in MediaWiki:Bs-usermanager-confirmdisableuser/en and MediaWiki:Bs-usermanager-confirmenableuser/en which need both $GENDER and $PLURAL; current message has $1 is a number for $PLURAL but the documentation speaks of $1 as a parameter for $GENDER.

Thank you in advance.

Already reported to and in work by the BlueSpice maintainer: https://translatewiki.net/wiki/Support#MediaWiki:Notification-bs-pageassignments-user-group-add-summary_58220

Hi, I'd like to request a review of Wikimedia:Citationhunt-instructions details/zh-hans please.

The original text is "Click %s to go to Wikipedia and {link_start}fix the snippet{link_end}, or %s to see another one. Good luck!", with two "%s" placeholders. The current translation only contains one "%s", which is not expected in the code. I can't read the translation but I wonder if the "or %s to see another one" part of the original message is missing?

Please let me know if there's another preferred way to report translation issues, I wasn't too sure. Thanks!

I have marked the message as outdated. Currently missing parameters are only a warning, should we make this an error?

Thank you! Yes, I think it would make sense to make it an error please. I suppose that means those strings will never be exported to the repository, right?

There's just a couple of things to watch out for, because this string handling code in Citation Hunt is not great:

• As you can see from the example above, there are two kinds of syntax for parameters in some strings ({this} and %s).
• Due to out of date translations, some strings now have _too many_, rather than too few parameters (e.g. https://translatewiki.net/wiki/Wikimedia:Citationhunt-instructions_details/pl has three %s, which we handle in the code, but it really should be two at this point).

But if those are OK on TranslateWiki, it's all good on my end.

Hello. Nias community needs to translate all the most used messages on the interface to make Wikipedia and Wiktionary approved. There is only one untranslated message there, but we can't translate it. When I try to publish the translation, it always says, "Publishing the translation failed: You do not have permission to edit this page because it contains raw HTML which can be modified to affect all visitors." Can somebody tell me how to make it published? Thank you. Rano (talk) 04:07, 29 November 2020 (UTC)

Hi Rano, please post the message name and the translation here. An administrator will publish it then.

MediaWiki:Copyright/nia to Nias language The translation is "Te'asogö nösi tou $1, hatö na fabö'ö niwa'ö."

 Done MediaWiki:Copyright/nia.

Thank you.

Could you please add Covid Ratio (source) to translatewiki? Thanks!

Do you manage this site ? Anyway it is focusing only US with few statistics per county. I don't think it's worth the value compared to international sites (including Wikipedia that follows lot of statistics).

And there's not a lot to translate: the country names ? They are in Wikidata. The rest is jsut a few messages. If the site author wants to make it a long term project for statistics independantly of country and division levels, may be, but the UI is too much in alpha stage and limited in scope. May be that site would want a few translations for other languages of US.

Such site is only useful if it tracks accurate data sources with regular updates and sources, but for now there's not even any indication of sources, so I would better trust official sites: WHO... or even Google (which in fact just uses and participates to the statistics project on Wikipedia/Wikidata for this topic, as this is a good place to collect and keep lot of sources and organize them...). and there are now tons of other websites for local statistics in each country, and for various platforms (web or mobile).

Yes I maintain the site. I'm totally open to adding more states/locales, but I do not have the time to go through each state's data source. As I mentioned in the footer the data comes directly from the Florida Department of Health, there isn't a more official source for county-level data than that. If any other developers would like to add other locals, please submit a PR on the GitHub repo. If you know of an API that gives out county-level data for the entire country, I would love to use that instead. :)

Oh... I did not even see this was even more limited to Florida only! Really, you should first ask for help on English Wikipeia at least to see if you get support for extending it to other US states, and possibly other countries. But I bet most won't be interested as Wikipedia already has a more complete dataset (and accurately checked, with all sources compared, not just one which uses one state-level method, and not the exclusive one at federal or international level). You should know that such statistics is highly sensitive to the methodology used, and there are many criterias (the WHO site gives some hints about their varaibility and what they are about, there's no single way to count things, including in one given country, and governmental sources are not always accurate on everything, frequently with underestimates!)

Such project is in fact not maintainable by a single person from his chair at home, it absolutely requires huge cooperation, at nation and international scale and requires monitoring as well other indicators. Even Google renounced to do that itself ! The best you can do however is to help the Wikipedia project if they are missing some data sources, in order to collect and track more (you MUST absolutely give the sources, as many sources use different methods or may be out of sync with others, using different time-frames for their measurements, and also frequently correcting their figures later).

Then you can use the data collected in Wikipedia and Wikidata to make a translatable app if you wish (exactly what Google did itself!).

English Wikipedia, nor Wikidata, maintain county-level data which is necessary to preform the calculation.

I'm not sure why I have to defend an applicaiton I wrote. If you don't want to translate the 7 strings, then just say so.

Even if I were to expand the data set (which I have yet to find a suitable one), the UI would still need those strings translated.

Hi David,

Thanks for showing interest in adding your project to Translatewiki. I've created an issue on our issue board and gathered all the information we currently have - https://phabricator.wikimedia.org/T268987

For now, these are the things we need from you, 1. Description of the project 2. A logo, if possible

In addition, please see the concerns I've listed on the ticket.

Regards,

Jen here from https://eol.org/ . I would like to display some form of attribution to the translators who have contributed to our project, in our About pages. I thought perhaps a word cloud similar to what is available at https://translatewiki.net/wiki/Special:SupportedLanguages/id. Is this consistent with translatewiki policy? If so, is there a recommended data service we should use?

Thanks!

Most projects thank "translatewiki.net translators". Some do collect all the names from their translation files and present that list as well.

Please courtesy vanish me, i accidentally created this account and then started doing some random stuff.

Just don't use your account here. Deleting an account is not possible.

I think the best we can do is to rename the account to a random string and prevent logins.

Some files on Wikimedia Commons have source codes published on their description page. It would be nice to have a {{int:source-code}} template to be used on headings as =={{int:source-code}}==; its use would allow translated texts such as "código fonte" in Brazilian Portuguese.

That should be translatable in Commons directly. They have a special message group for that kind of messages. Maybe you can request it to be included there, if it isn't yet?

Hello, I saw that translatewiki.net does not have a mobile view composed of the extension MobileFrontend and the MinervaNeue Skin. Please you can to add a mobile view to translatewiki.net? Thanks.

MobileFrontend is a rather expensive extension to maintain, so I don't think the translatewiki.net staff has enough resources to provide this option. However, work is ongoing to switch to the Timeless skin, which is more responsive and should address most concerns: Thread:Support/Proposal to change default skin to Timeless. I suggest that you enable the Timeless skin in your preferences and report any issues you find.

I suggest that MobileFrontend and Minervaneue must be enabled to translatewiki.net, is because is more responsive in mobile devices. And also I opened a task in Phabricator at https://phabricator.wikimedia.org/T268340.

And I disagree, for the reasons above.

Hello, we want to translate the content (Wp/trv) of MediaWiki (most important messages).One of the sentences (Content is available under $1 unless otherwise noted.) is not allowed us to publish our translation. And the reason is you do not have permission to edit this page because it contains raw HTML which can be modified to affect all visitors.We would like to know how can we solve this problem？

This is not strictly for Mediawiki as what you wanted is to translate the Wikipedia Incubator for Portal:Trv (Taroko, Seediq): the UI of the wiki effectively comes for Mediawiki (so the Incubator wiki itself does not allow modifying it locally), but this could have happened for other projects as well. You have two solutions:

• contact a local wiki adminsitrator to make a change for you (it will be kept specifically on that wiki by adding another level of protection that will block reimports from Translatewiki.net, where it may be translated differently in a more generic version not specific to Wikimedia).
• or find the relevant message on this Translatewiki: if you can't edit it here, then propose the translation to this Support, and an admin will submit it for you: please link the message

I've try to locate it, and found 4 resources (here in English, two for MediaWiki itself (they must be generic):

• MediaWiki:Copyright/en, which contains

  Content is available under $1 unless otherwise noted.

• MediaWiki:Mobile-frontend-copyright/en

  Content is available under $1 unless otherwise noted.

and two for Wikimedia-specific contents:

• Wikimedia:Pagecontentservice-license-footer-text/en

  Content is available under $1 unless otherwise noted.

• Wikimedia:Wikipedia-android-strings-page footer license text/en

  Content is available under $1 unless otherwise noted

Note that the reason given ("raw HTML") is not relevant as there's no raw HTML in fact. But that protection was required for legal reasons, because these messages are required on many pages (for legal reasons) and they must not be altered without careful check and approval by site admins.

So you have to give the translated text to put into

• MediaWiki:Copyright/trv (it is protected), was in Chinese, now it contains:

  Rahuq nan ii o niqan kingal duri pgkla, aji saw kiya do ruwan ruwahan patas dmuuy kana $1 gaya mgay biyax kklawa.

• MediaWiki:Mobile-frontend-copyright/trv (not protected, it is editable by you), was already translated, it still contains:

  Rahuq nan ii o niqan kingal duri pgkla, aji saw kiya do ruwan ruwahan patas dmuuy kana $1 gaya mgay biyax kklawa.

• Wikimedia:Pagecontentservice-license-footer-text/trv (not protected, it is editable by you), it contains:

  Rahuq nan ii o niqan kingal duri pgkla, aji saw kiya do ruwan ruwahan patas dmuuy kana $1 gaya mgay biyax kklawa.

• Wikimedia:Wikipedia-android-strings-page footer license text/trv (not protected, it is editable by you), it contains:

  Rahuq nan ii o niqan kingal duri pgkla, aji saw kiya do ruwan ruwahan patas dmuuy kana $1 gaya mgay biyax kklawa.

@Raymond: Thanks for your help. The translation is "Rahuq nan ii o niqan kingal duri pgkla, aji saw kiya do ruwan ruwahan patas dmuuy kana $1 gaya mgay biyax kklawa." Please help us to add the content.

I have created MediaWiki:Copyright/trv for you. Please check the content. If you need further help please add the message name and the translation here.

CLOSED This issue is closed by Amire80

asked at phab:T171347#3925633

Language Saraiki is mainly written in Arabic script. So Skr and Skr-arab be merged. In wikimedia and other sites Skr-arab be deleted. Because Saraiki is just one language. In interface language and internationalization only one langauge be shown. Interface of Urdu words be adjusted as they are adjusted in SKR_Arab. All translations be converted to Skr i.e., Skr-arab be renamed as skr. so that one language Skr-arab be deleted from Special:SupportedLanguages. In language selector of Wikimedia Saraiki is Written two times. Kindly Skr-arab be deleted.

Merging messages between two variants can be easy for sysops by using Special:mergehistory, but I'd love to know what's your actual wanted code (aka merge which to which)? Merge skr to skr-arab? Or vice versa?

In interface language merge Skr-Arab in Skr، In interface language the all work as stood as in Skr-Arab be adjusted as Skr, and the word Skr-Arab be deleted in the the internationalization of the the language. Wiki is only in Skr. Please this conflict be removed. Saraiki. (talk) 10:45, 1 August 2017 (UTC).

@Amire80: ^^

Sorry, for technical it will be too complicated to do this. However, it doesn't matter because the "skr-arab" code will remain internal, and you'll see "skr" in the actual sites.

In summary we jsut want to make sure that [skr] is an alias for [skr-Arab] by default, just like [zh] is in alias for [cmn], or [en] is an alias for [en-Latn].

Like for all aliases, they are to be treated equivalently, except for the purpose of fallbacks with BCP47 rules, where the extra script code can be used as a guide to select one of several possible languages using the same script. This does not mean we create duplicate data for localization, but that where data is missing, fallbacks will resolve differently for languages that may have different scripts, even if one of them is the current standard or the most frequently used.

• e.g., English is not written only with the Latin script, it may still be written with Deseret, so [en-Dsrt] is still a distinct variant, but if it's missing it will fallback to [en]
• for Serbian, the Cyrillic script is the default so [sr] can be aliased to [sr-Cyrl] (or [sr-ec] only in Wikimedia wikis which violates the BCP47 standard here) and we don't need to have the two datasets for [sr] and [sr-Cyrl] (they should be identical), but we can still have [sr-Latn] which fallbacks to [sr] (and thus, also to [sr-Cyrl] because it is equivalent by its alias), however it can also fallback first to [sh-Latn] which will itself fallback to [hr-Latn]).

We can consider that for fallbacks, preserving the script is preferable to preserving the base language; so the two aliased codes are not completely equivalent: they are only equivalent in translation datasets, but not in applications that will use them with their own fallback chains to decide the order of resolutions.

If no fallback is needed (because a translated resource is found in any one of the two aliased datasets, which are in fact just the same one), using one code or the other does not matter. So in this TWN wiki, nothing needs to be changed except making sure that there's only one dataset open, the other being locked, or "redirected" to the other code.

So I would recommend keeping [skr-Arab] here, and keep [skr] closed/locked, with a possible redict. On the [skr] portal, we can display the shorter code, but as well all variants including [skr-Arab] as the default variant. The short code will be locked, all translations will be made in the unambiguous [skr-Arab], except if another script is used, like [skr-Cyrl].

It should be noted that [skr] was just approved by the languages committee of the WMF, for creation of Wikipedia at least. For now all Wikimedia projects are still in Incubator.

Here on this wiki, it will remain [skr-Arab] (which is already enabled), even if there are 3 other scripts (including an historic Indic abugida, Multani, which was specifically used for that language; plus Devanagari and Gurmukhi, or Latin transliteration sometimes used today.) This won't block the import and creation of the new Wikimedia wikis (using mainly the Arabic script) as they work already in Incubator: the code [skr] can then remain disabled on Translatewiki.net (and because it was already disabled, there's no need to merge an inexixtant [skr] dataset with the existing [skr-Arab] dataset).

See the request made by Kambai Akau on Category talk:User languages.

Hi. The Southern Luri language(luz) name is misspelled and needs to be corrected. How can I change it from "لئری دوٙمینی" to "لری دۊمنی"?

It's the name built into MediaWiki for the "#language:" parserfunction, and its source is the name imported from Unicode CLDR, where it was vetted. It seems that the name is correct is I look at Wikipedia which cites it as well. The difference being in the optionaml notation of vowels, which may be simplified (your proposal) or more advanced. I do not see a typo, and the CLDR vetted data is considered reliable (a defacto worldwide standard for translation of language names, beside the ISO 639 standard and the IANA database for BCP47 that just give English names). If I look at Glottlog and the Linguist list, we see several orthographic variants for the native language name (they vary depending on authors, sources, or time, or location of the author using an orthographic system from several possible countries).

Hi, I have noticed two small errors in the original while I was translating SWViewer:

https://translatewiki.net/wiki/Wikimedia:Swviewer-about-frame-data-ref-2/en

Should say "This data is available to the public."

https://translatewiki.net/w/i.php?title=Wikimedia:Swviewer-about-frame-data-desc/en

"Appication" instead of "Application"

Best,

Shouldn't data be plural only (and collective, uncountable) in English so that it should be:

These data are available to the public.

To speak about a single data element or to count them, you need another noun: "piece(s) of data", "data element(s)", "data item(s)"

These have been fixed.