View source for Thread:Support/zh-hant

From translatewiki.net
Jump to navigation Jump to search
NoteProblems? 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. Very old threads have been archived.
(The thread summarization feature is broken, see: Phab:T245109)

First page
First page
Last page
Last page

RC Wikidata

I'm searching for the MediaWiki-page that shows "Show/Hide Wikidata" in the Recent Changes. Anyone know which one that is? --Ooswesthoesbes (talk) 09:52, 20 July 2017 (UTC)

Ooswesthoesbes (talk)09:52, 20 July 2017
Edited by 0 users.
Last edit: 01:02, 27 July 2017
Liuxinyu970226 (talk)01:02, 27 July 2017
Edited by 0 users.
Last edit: 10:42, 31 July 2017

That might be it. Thank you!

Ooswesthoesbes (talk)10:42, 31 July 2017
 
 

Error on MediaWiki:Wmobile-copyright/en

Hi, can someone change MediaWiki:Wmobile-copyright/en to use quotation marks rather than apostrophes in the links as they're currently broken

Thanks

Nintendofan885T&Cs apply14:25, 26 October 2020

Single quotation marks are valid in the HTML syntax for attributes.

Remember that this resource is NOT written using the Mediawiki syntax, but the plain HTML syntax, so even if it does not render correctly on this wiki, this is only because this wiki attempts to parse it as Mediawiki (where even the <a href="URL">text</a> is not permitted by the wiki; so if it was written using the MediaWiki syntax and rendered by MediaWiki, it would be .[URL text] instead; this is not the case here).

So changing the ASCII single quote to ASCII double quotes would not change the way this message is rendered here on this wiki. Keep it in plain HTML: the message is intended to be rendered only locally by the Mobile app (which uses its own internal HTML renderer with its own embedded browser component, and does not parse the Mediawiki syntax, this text is emitted as is) and NOT on a MediaWiki server...

Nothing is broken here!

Note: you are still free to change these quotes in translations, as long as you use a valid HTML syntax (so don't change the ASCII < and > delimiting the HTML opening and closing tags. As well only use a plain URL (which you may need to change if it has to link to another translated page on the same target site, and keep the "https://" protocol unchanged).

And you are free to use the the quotation marks and apostrophes and all other punctuation appropriate in the target language for the text part of the link. You can test your translation by copy-pasting it in a plan-text file saved in ".html" format, and open it in your browser (unfortunately, the source message is not "meta-tagged" as using the HTML syntax; that's something that Translate wiki should propose to indicate its expected syntax, but that would also involve importing the source message with metadata in the package).

Such message, given it contains plan HTML, should also be modifible only by admins (to avoid injection of dangerous HTML code, such as link to spammed sites, or injection of bad javascript attempting to steal data or break the privacy in the Mobile app). This is something that authors of the Wmobile app should change: they can preprocess this message to generate the HTML code they will inject in their app (without the need to integrate a MediaWiki parser phase in the app itself), and only use Mediawki syntax on this wiki. But anyway this wiki is itself protected and renders the plain HTML link code, so this wiki remaing protected.

Verdy p (talk)18:01, 26 October 2020

Oh, I thought it was broken because the links broke when I clicked on them (it went to http://en.wikipedia.org/wiki/Wikipedia:Text_of_Creative_Commons_Attribution-ShareAlike_3.0_Unported_License')

Nintendofan885T&Cs apply20:38, 26 October 2020

This is a parsing bug of MediaWiki on this wiki; this won't occur with a regular HTML parser. As I said, plain HTML links are not supported by Mediawiki as Mediawiki incorrectly includes the "trailing" quote in it. That's something that MediaWiki should fix as these quotes in HTML are never taken into account, unless they are URL-encoded in HTML.

Note that in HTML both the single quote and the double quotes are valid delimiters for attributes, and which ones are valid as part of the quoted value depends on which delimiting paired quotes are used:

  • If attribute values are between double quotes "...", litteral single quotes ' in the embedded value don't need to be encoded, but double quotes in attribute values have to be HTML-escaped as &quot; (or only if the value is an URL, they can be URL-encoded as %22, which won't need any HTML-escapes)
  • If attribute values are between single quotes '...', litteral double quotes " in the embedded value don't need to be encoded, but single quotes in attribute values have to be HTML-escaped as &#39; (or only if the value is an URL, they can be URL-encoded as %27, which won't need any HTML-escapes)

Note that any single quote or double quotes by IS valid in any standalone URL (except for the leading protocol part or the host/domain part, it is valid anywhere in the optional parts: the path, the query string, fragment identifier) or any URI. Inside a standalone URI, there's no support at all for the HTML-encoding, or for the URL-encoding (which depends on the protocol and the target host/domain part in its own URL parser, but noit at all of the HTML-parser!!!).

Here MediaWiki (on this wiki) does not parse the HTML completely correctly and so it does not use the correct HTML-parsing for delimiting attributes, and then it considers the value as if it was between double quotes (no check is made about which effective delimtier is used in the HTML attribute, so it incorrectly accepts the single quote as part of it, then it takes the wrong decision).

This is effectively a bug of MediaWiki (which could be reported given that the MediaWiki should still parse HTML correctly and should be an extension of it), in its own custom parser. But as I said, this message is *not* to be parsed by MediaWiki and will be parsed by a regular HTML parser which makes the correct decision. The bug is bisible on this wiki when viewing the translated page, but it does not affect the application.

Verdy p (talk)23:17, 26 October 2020
 
 
 

Transadmin

How can I be a transadmin?

--ToprakM 13:46, 24 October 2020

[Sxr] [Xnb] Translation of MediaWiki interface is not supported by translatewiki.net

Edited by another user.
Last edit: 07:37, 24 October 2020

Hla’alua Wikipedia (incubator:Wp/sxr) and Kanakanavu Wikipedia (incubator:Wp/xnb ) ,both are open test wiki of the Wikimedia Incubator. There also have valid ISO 639 language code. Due to approval of Wikipedia, translation of MediaWiki interface into their own language in the translatewiki.net is one of the requirements before a wiki can be created. But now translatewiki.net said that there are not yet enabled. We would like to know what steps are necessary to get the language enabled.

Mecytan (talk)02:46, 22 October 2020

These two related Tsouic languages (originating from a small central area in Taiwan) have their portals (Portal:Sxr, and Portal:Xnb), created since long in 2017, which you can subscribe as a translator. They also indicate already their Incubator wikis.

They are still disabled as there's no support for now in the Translator tools and statistics. Languages are enabled for translation when there's a demand and a convincing desire to start translating them (probably starting by the Mediawiki interface). However, even if this is still not enabled, you can work on these incubators and develop there some pags of terminology that you may want to discuss, and that may be needed to start translting the Mediawiki UI on this site.

This suppoort page is to demonstrate you commiment to this project and ask these to be enabled (but note that if there's no progress or there are signs that you don't work actively with Wikimedia to support the import on the Incubator wiki or on a test wiki, this could be disabled by the Translatewiki.net admins until there are more contributors taking the project seriously, notably because generating the exports from Translate.wiki.net has a cost that should find a usage on an actual wiki (Wikimedia Incubator is supported but you also need an agreement with other users of its local community to monitor the initial progress and ask for a reasonable review)

Another thing you msut discuss is some additional support in Incubator itself and in the Wikiemdia multinigual tools. Now if the Incubator goes well to the creation of a new Wikipedia, of course these languages should be enabled because the support for these languages will be demonstrated. Note that Wikimedia wikis are not the only projects that you could be working on. For example you may want to translate OpenStreetMap tools, or communication tools that are hosted on this wiki, or would like to develop a wiki for any topic outside Wikimedia, that would benefit as well of the translation of the MediaWiki UI.

You made the appropriate step here. Hope your arguments will be enough to convince an adminsitrator of Translatewiki.net for you (I cannot do that myself).

Verdy p (talk)03:08, 22 October 2020
 

Hi,

I can do this, but I want to make sure first: Who is going to do the actual translations? The two languages have very few speakers. By itself, it's not a problem, but the pages in the Incubators are quite repetitive, and the activity in the Incubators is quite low. Are there people who speak these languages, know them well, and plan to work on localization?

Amir E. Aharoni (talk)15:00, 22 October 2020
 

Parameters for illustration

These words are in the Chechen Wikipedia in Russian. Did I do something wrong?

"img_right = аьтту, справа img_left = аьрру, слева img_center = центр, центр img_frameless = гура_боцуш, безрамки"

MediaWiki:Sp-translate-data-MagicWords/ce

Умар (talk)23:55, 21 October 2020

Your edits to MediaWiki:Sp-translate-data-MagicWords/ce have no effects, sadly :-( The process to export such edits from translatewiki to Wikipedias & Co are broken since years. You (or someone else) have to submit a patch to this file: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/master/languages/messages/MessagesCe.php#224

Raymond18:11, 22 October 2020
 

Known issue with Timeless

Just heads up that during the latest code deployment today we noticed an issue with the Timeless skin. The echo notification icons are misplaced. We have reported the issue at Phab:T266135 and will deploy a fix once it is available.

Nike (talk)14:28, 21 October 2020

Rename my username

Can you please change my username to Awesome Aasim? I have done so on other MediaWiki wikis, but not here.

Ups and Downs ()09:41, 20 October 2020

Done Done

Raymond07:19, 21 October 2020
 

MediaWiki Visualeditor tooltips (Slovenian)

Hello!

I'm looking for translations of MediaWiki buttons for insertion of special objects to translate them to Slovenian and can't locate them.

I'd need help with the following:

  • Chemical formula
  • Map
  • Graph

Thank you!

Eleassar (talk)09:23, 26 August 2020
  • chemical formula and more from the Math extension
  • graph and more from the Graph extension
  • map and more from the Kartographer extension
Raymond15:57, 27 August 2020

Thank you, @Raymond:!

Eleassar (talk)13:21, 20 October 2020
 
 

Could someone change the <tt> to <code>? Thanks.

Edit: There are also obsolete <tt> codes in this link: https://translatewiki.net/w/i.php?title=Special:SearchTranslations&query=tt&language=en

MuratTheTurkish (talk)09:04, 14 October 2020

I don't like the fact that "code" is "decorated. "tt" just implies a monospaced font and no decoration (which changes the line-height). Such deprecation is badly welcome. The alternative is "kbd". Anyway this "deprecation" is the result of a bad decision, given it is still fully supported in HTML5, and "code" has a different semantic which implies the use of a colorization in a supported programming language (which is not specified here, so it implies a default behavior as plain-text, which is wrong when it may contain internationalisable text)...

Verdy p (talk)18:34, 14 October 2020

Very bad then. That obsolete tag will completely removed in the future. I don't agree some users when they still want to use deprecated tags. Anyways, thanks for the information.

MuratTheTurkish (talk)18:58, 14 October 2020
 
 

New special page names for Kurdish (Latin script) [ ku-latn ]

Hello, we want to translate some of the current English names into Kurdish and update one Kurdish translation for special pages (Special:... (Taybet:...)).

Discussion: https://ku.wiktionary.org/wiki/W%C3%AEk%C3%AEferheng:D%C3%AEwan#Guhertina_nav%C3%AAn_r%C3%BBpel%C3%AAn_taybet

In short,

  • LonelyPages -> Rûpelên_sêwî
  • WantedPages -> Rûpelên_xwestî
  • Guherandinên_dawî -> Guhertinên_dawî
  • WhatLinksHere -> Girêdanên_li_ser_vir
  • Contributions -> Beşdarî
  • Watchlist -> Lîsteya_şopandinê
  • Preferences -> Tercîh
  • Notifications -> Agahdarî

Thanks.

Guherto (talk)18:02, 6 October 2020

Hi Guherto,

I have created a patch special pages of MediaWiki core (all except Notifications): Gerrit:632913

The patch needs review. Please check my pach too.

Patch for Notifications follow.

Raymond13:21, 8 October 2020

Thank you, Raymond.

Guherto (talk)15:13, 9 October 2020
 

Patch create for Notifications (Echo extension).

Gerrit:632917.

Raymond13:36, 8 October 2020
 

{{int:Lang}}

Edited by author.
Last edit: 18:09, 20 September 2020

You do not have permission to edit this page, for the following reason:

The action you have requested is limited to users in the group: Users.


You can view and copy the source of this page.

 

Return to Thread:Support/zh-hant.

Yes We know. There's no support on this wiki.

  • missing code in the Mediawiki hook implementing the "int:" namespace, so it just performs normal lookup of subpages in "MediaWiki:Lang/*" that would need to be created just to contain the same language code used in the subpagename; these pages are not present and maintaining them is long and not efficient; as these resources are not found, all you get is this fallback static text: ⧼Lang⧽
  • no other way to get it from one of the extensions with a custom magickeyword
  • no way to get it from Lua as Scribunto is not installed.

This just means that the rendering (and caching) local pages on this wiki never depend on the current user language (they just depend eventually on the current time or some statistics available about this site with other magic keywords, forcing these pages to expire in caches sooner, and be parsed again). As this wiki runs on a small server, may be this is wanted, however the wiki has many extensions loaded, some of them being very costly (and useless for now, like SemanticMediaWiki which causes troubles). Still there are some contents that are sensitive to the user language, such as statistic graphics shown on "portal:" pages. That's very strange for a wiki that is supposed to be opened to user languages and that promotes translation and translatability, it is not making itself a good demonstration of how the work we do to translate the various projects (including Mediawiki) can also be useful for this site (a Mediawiki-based wiki). This forbids making some local tests: things get translated here, then exported later, imported in other wikis where bugs are noticed, then corrected here (may be) or locally on the target wiki (with overrides, that will then be protected by admins to avoid them to be rewritten by the imports, and finally all work made here or any changes are no longer imported on the target wikis). This causes a break in the translation work cycle, for Mediawiki or for all hosted projects, unless these hosted projects all have a live demo site showing the result early before feeding the actual projects. anyway this lack of {{int:Lang}} has no severe impact on this wiki as there is very few contents outside the translate UI for projects, the portals. And there's almost no article or help page or templates to translate here: all portals are almost monolingual, the only multilingual part is the support page where each posted message is threaded in separate pages in their own language used directly by each sending user (and not translated automatically, users will post add the necessary translations manually below). The portals are just posting lists of links (possibly to other sites) with few details, and this wiki remains small. Verdy p (talk) 13:28, 20 September 2020 (UTC)

Verdy p (talk)13:28, 20 September 2020

I see. Thanks.

Pseudo Classes (talk)13:42, 27 September 2020

Note that I am not the admin of this site; I just help to maintain it so that it remains coherent within its existing limits. The intent is not really to create new contents: the "hosted" projects are here only for one goal: create translations for messages that each project want to localize. The purpose is not to make development, but just create the basic structure that will help translators (not technicians) to do their work appropriately for each language, using the current best known classification and differentiation of languages. That's thy there are:

  • portals for each language, but they are very basic: they just provide some basic links to relevant sources, help people join together, to work across multiple projects that may be translated in the same language. Most discussions for such things will occur in well-known linguist lists (for that we provide codes for relevant standards, and well-known external sources, and in portals you can add a few). On each of these portals, users can register themselves just by pointing to their own user page, where translators can also point to their home pages for any kind of project they want to support (including other projects not translated here). This is a just point of contact.
  • portals for each hosted project: talks about them occur in the relevant maintenance site for each project independently of the language, but there's sometimes the need to create a specific terminology for this project that is difficult to reach but influences how these would then be translated (with more or less difficulties, or specific technical limits that are often independent of the language or script used), so the talks there are more technical but scoped only to the internationalization aspect of the hosted project. If the project already has a dedicated section for this part, it will be enough to just point to it. So there's little actual content here too. And contributors in those sections should still be multilingual but would be more English-savvy than in the previous type of portals.
Verdy p (talk)14:30, 27 September 2020

Thanks. So does this mean I can't create subpages to solve this problem? Sorry, I am not online often and thus there is a delay in reply.

[使用者:偽類]偽類= ([用戶談話:偽類[談話])09:40, 8 October 2020
 
 
 
 

Mediawiki:Blocked-notice-logextract/fr and Mediawiki:Sp-contributions-blocked-notice/fr

Hi,

These two messages support the magic word GENDER:, it’s written in the /qqq and it works fine in the French Wikipedia (where they are hardcoded for the moment: [1] [2]), but for some reason they are marked as !!FUZZY!! and the magic words keep getting reverted (ping Gomoko).

Could someone fix this?

Thibaut (talk)12:51, 2 September 2020

German uses GENDER for these messages too without problems. Maybe Gomoko can explain his/her edits?

Raymond14:56, 2 September 2020

Most probably this is because the original English message makes no reference to any variable. Then the "Fuzzybot" changes what is edited and marks it as fuzzy, as if we forgot to remove a reference to an older variable (whose name or ordering would have changed in past versions.

This can only be fixed if the English version makes an explicit reference to {{GENDER:$1|}} even if it is empty in its second parameter or contains a single text (which will be still displayed independently of the variable.

The fact that a variable is marked as "supported" by the underlying app or in the "/qqq" doc page is not enough. Such variable should be present in the source message, even if its value is not used in English or does not change anything.

I tried to use the GENDER there too, I got the same behavior. I don't kwno why it works in German (may the German version was validated BEFORE FuzzyBot makes this check, and not modified since, so FuyzzyBot sees no reason to change it after edit if there's no edit at all.

Note: I the German version is *also* marked now as fuzzy (even if did not change since 2015. The source English message also did not change since 2010).

Or may be the German version was not created by using the normal Translate UI or the normal wiki editor, but by an admin-only tool (such as ReplaceText) whuich can bypass any action made silently by FuyzzyBot or any other deployed hook for Mediawiki on this wiki (this tool makes direct access to the underlying data store, nothing is checked, that's why this tool is reserved to admins only). In summary, ask to the maintainer of the English version to include this variable in the source, even if its value does not change the generated message.

So this can only be caused by a new rule added in FuzzyBot, making SILENT edits (invisible in the history log of the edited pages): Click the "Edit" link on any page. Don't change anything, save the page as is: Noting will be reported in the history log of the page, but FuzzyBot performs changes (it never even adds any tag for the pages that it marks as "FUZZY". Most probably, the "!!FUZZY!!" mark is not even part of the wikitext, but saved as a separate status, it only becomes visible in the wiki editor where it is automatically prepended to the wiki text in the input form.

Each time you press the "Save changes" button in the Translate tool or the wiki editor, there's some hook on this wiki which allows Fuzzybot to check if "!!FUZZYBOT!!" is still present at started (it is silently removed from the actual wikitext, but the fuzzy statis is kept to be set) otherwise Fuzzybot parses the edited text and compares it to the source text, to detect placeholders: if there's any mismatch (notably references to variables that are not part of the source text, it forces the "fuzzy" status. But no change will be really made to the wikitext which is still saved as is (so there's nothing visible in the page's history). Still the status is applied and kept in a specific separate data table of the local database (this table is not part of the core Mediawiki engine).

This really means that

  • But really the English source message should be updated to explicitly contain a reference (even a dummy one) to the "GENDER" magic keyword and to the "$1" placeholder. This requires action by MediaWiki developers to reimport a new version of the English source message to this wiki.
  • This is also another bug in the Translate tool : FuzzyBot makes silent modifications and is not auditable. Only some admin can use admin tools to remove these incorrect status inside the SQL store. This requires action by developers of Fuzzybot for the Translate tool (notably a way to list additional supported variables or magic keywords that can be used in translated messages even if they are not present in the source message, and a modification of the UI for the Translate interface so that it can list these supported placeholders/variables, and some additions to properly tag the syntax to parse the source and target message: Mediawiki / PHP/ C /C++ printf formats/ Java / Javascript I18n/ etc. ? or other flags like restrictions on some forbidden characters, or case folding/normalization, or some custom regexps for filtering whitelisted or blacklisted text fragments, and other options similar to those used in online translate tools for .po/.pot files used in many opensource projects, or other common formats like resource bundles in java, XML-based formats, HTML with a way to associate them with pluggable parsers...)

Two bugs in one (but 3 separate actions to fix it by different admins, plus an admin action on each target wikis where the translated message will be imported) !

  • For now, a local admin on this wiki must use "Replacetext" or some similar SQL tool to remove the status (we know that admins on this wiki have lot of work and have a long list of reported problems they don't fix, including those related to incorrect permanent lokcs left by the "SemanticMediawiki" extension in many categories). Normal users cannot set this status with the existing UI. They just see the result because what is visible is not what they edited and saved themselves.
Verdy p (talk)19:11, 2 September 2020
 
Raymond09:52, 3 October 2020

Patch submitted and live on translatewiki. The messages should not longer throw an error/fuzzy.

Raymond13:31, 5 October 2020
 
 

Change Username

Hello

I would like to change my name to eduaddad

Eduardo Addad de Oliveira (talk)17:59, 21 March 2019

I would like to delete this account to make sure the username migration

Eduaddad (talk)18:03, 21 March 2019

Just to confirm, you want "Eduardo Addad de Oliveira" to be deleted right?

Abijeet Patro (talk)14:15, 11 March 2020
 
 

Username change

Request username change: ghkdekdns71 → Drhyme

Ghkdekdns71 (talk)14:38, 29 September 2020

Done Done

Raymond04:57, 30 September 2020
 

Username change

Hi, can I request a username change to stonecy, please? Thank you.

Grkn gll (talk)17:12, 24 September 2020

Done Done

Raymond05:41, 25 September 2020
 

Someone please revert my last few 50+ edits to British English MediaWiki massages

I recently made more than 50 and less than 100 edits to British English MediaWiki messages, because I accidentally did not notice that my translation language was set to British English. Sorry! Would someone be able to revert all my recent edits to British English MediaWiki messages? Just check my contribs to see them.

Heahwrita (talk)07:20, 23 September 2020

Done, thank you for asking promptly.

Nemo (talk)07:24, 23 September 2020

Many thanks.

Heahwrita (talk)08:02, 23 September 2020
 
 

GRAMMAR for Rusyn

Hello! Would it be possible to create GRAMMAR files for Rusyn (rue) please? So far I've only seen it with project names. Wikipedia is the only project in Rusyn (except for translatewiki and Wiktionary in Incubator) - please let me know if it would be preferable to just use the word for Wikipedia instead of SITENAME then. Here is the declension for Wikipedia:

default nominative form: Вікіпедія

genitive: Вікіпедії

dative: Вікіпедії

accusative: Вікіпедію

instrumental: Вікіпедіёв

locative: Вікіпедії

Thank you!

Tkalyn (talk)10:54, 18 September 2020

Is that grammar enough documented (e.g. in Rusyn Wiktionnary or a relevant article that can be reviewed? or some reliable sources?) Declensions are frequently complex and have many exceptions, it's not easy to formalize it it a simple automated function without lot of data and it's not always just a word list because there are also usages, and complex mutations depending on the context and not a single isolated word). That's the same for the complex rules related to transliterations and conflicting orthographic conventions even in the same script (see for example Belarusian). That wiki is not the place where this can be developed: Phabricator would be a more appropriate place to track the project and the plan the efforts needed or evaluate the first proposed solutions (which will almost allways be partial and not working to cover all cases). Human languages are complex, they have a complex history and borrow lot of exceptions from other related languages and social interactions that evolved over the history of peoples and their migrations or invasions (aggressive or progressive). When a language becomes used only as a minority (this is the case of Rusyn) there are no longer strong rules, many forms that would have seemed first as being incorrect become standard, and people forget their historic language or develop new variants which may become divergent with lack of mutual understanding or that cause conflicts of interests.

Verdy p (talk)19:36, 18 September 2020

Hello, there are normative Rusyn grammars that we use in the project, that contain declension information. In this specific case, the word for "Wikipedia" can only have the forms listed. Any other words would also have a limited number of forms. I don't know if there are even any other words that would be needed since I've only encountered grammar being used with SITENAME.

Tkalyn (talk)01:15, 22 September 2020
 
 

Translating namespaces (MediaWiki)

MediaWiki: Romanian: Please translate "Gadget" to "Gadget", "Gadget talk" to "Discuție Gadget", "Gadget definition" to "Definiție gadget", "Gadget definition talk" to "Discuție Definiție gadget" "Campaign" to "Campanie" and "Campaign talk" to "Discuție Campanie".

NGC 54 (talk)09:42, 17 September 2020

For the Gadget extension: The upper/lower cases look a bit inconsistent. Could you confirm this pls?

$namespaceNames['ro'] = [
	NS_GADGET => 'Gadget',
	NS_GADGET_TALK => 'Discuție_Gadget',
	NS_GADGET_DEFINITION => 'Definiție_gadget',
	NS_GADGET_DEFINITION_TALK => 'Discuție_Definiție_gadget',
];

Campaign is part of the UploadWizard extension. Currently no way to localize the namespace, see Phab:T134078

Raymond13:44, 17 September 2020

I confirm.

NGC 54 (talk)15:41, 17 September 2020

Thanks. Patch committed waiting for review.

Raymond07:05, 18 September 2020
 
 
 

Make Osm:Browse.common_details.coordinates_html, Osm:Browse.note.coordinates_html and Osm:Diary_entries.location.coordinates optional

Their documentations (common_details, note, diary_entries) say “Leave untranslated to use the default for ‘en’.” This sounds much like optional messages.

Tacsipacsi (talk)09:22, 17 September 2020

THe description may be just an indication. In my opinion it is superfluous indication, as all translatable messages use "en" for their default, as long as they are not translated. Note translating them is still a bad idea: it's still best to confirm that the English term is actually the one used for "coordinates", which is obviously not correct in all non-Latin languages and most Latin-written languages that have their own word (even if it's an orthographic variant). E.g. in French, "coordinates" would look wrong, we want "coordonnées"...

Optional messages are for things whose translation is not needed for common users, e.g.

  • messages in technical logs, mostly intended for being reported to a bug maintainer, and not directly part of the UI (even if you can see them by pressing a "Detailed" button, or if they occur on the middle of log files containing many untranslated items such as fragment of code, track traces, encoded values in hexadecimal or compressed bitfields, locale-neutral timestamps, CPU/resource usage, objects/classes names, API names...
  • or if they are about messages only seen by a few authorized admins of the service; or just a few users choosing to use an "advanced mode" or participating in "beta tests".
  • or if they are about transitory messages that won't last for long, waiting for another solution to be finalized and deployed.
  • this also concerns many untranslatable names like brands (which are often restricted in the number of translations that they registered for specific markets) or people names (if they have several public identities for specific markets or specific uses such as romanizations of Chinese people name, which are not easily transliterable unless these people transliterated these names themselves and registered them to get some valid status for their travels abroad or their international business).
Verdy p (talk)12:35, 17 September 2020

I think you misunderstood what these messages are about. They don’t translate the word “coordinates” (which should be translatable, as it’s likely to be different in other languages), but just the comma separator—just like MediaWiki:comma-separator from MediaWiki core, which is optional.

Tacsipacsi (talk)14:04, 17 September 2020

Done.

Nike (talk)14:56, 17 September 2020
 
 
 

names of languages (gcr) and (hyw) in French

Hello,

The name of Guianian Creole (gcr) in French is "créole guyanais" ([1]). The name of Western Armenian (hyw) in French is "arménien occidental" ([2]). Currently, the names of the languages on the links from the french wikipedia to wikipedia in these languages is displayed in English. Can you please insert the French names above? Otherwise, please point me to the relevant support board. This request was deemed out of their scope by CLDR [3].

GrandEscogriffe (talk)18:35, 14 September 2020

C'est déjà bon maintenant en français pour les noms affichés sur les portails de ce wiki et la description des catégories (voir Portal:gcr et Portal:hyw).

Pour l'arménien oriental, pour l'instant il est groupé sous le code de macro-langue "hy" (arménien sans précision, l'arménien oriental restant utilisé par défaut si pas de traduction en arménien occidental, qui est de création plus récente)

Pour traduire les "#language:" (mot-clé magique de Mediawiki), ça se passe ailleurs (dans la base de données CLDR des noms de langues pour BCP 47, et sinon dans la localisation de MediaWiki lui-même en attendant, à demander aux admins développeurs de Mediawiki et chargés du déploiement sur les sites Wikimedia qui peuvent définir des surcharges spécifiques à Wikimedia y compris pour des codes non conformes à BCP 47). Ce n'est pas fait ici, hormi pour quelques projets qui proposent de traduire ces noms dans certaines unités de traduction correspondant à leurs besoins propres! pour faire la demande à Wikimedia, aller sur Phabricator, il sera décidé ensuite si cela va dans Mediawiki ou seulement dans un patch spécifique de déploiement interne pour les wikis de Wikimedia (et pas forcément tous non plus: le patch peut aussi être intégré dans des modules PHP spécifiques à chaque wiki, par les admins de chaque wiki ayant le droit modifier ces fichiers de ressources PHP qui modifient le comportement par défaut de Mediawiki, lequel s'appuie uniquement sur les imports de CLDR, donc sur les votes des participants sur la plateforme d'Unicode).

Sans intervention des admins de chaque wiki, la solution la plus rapide est d'utiliser un modèle wiki local qui, comme ici, va utiliser #language: en dernier ressort (fallback par défaut) pour les paires de codes de langues non pris en charge par le modèle lui-même. un tel modèle wiki ne demande pas de demande spéciale, mais il est à faire accepter par les communautés de chaque wiki. Sur Wikimedia Commons ce n'est pas un modèle wiki mais un module Lua qui vient surcharger le mot-clé "#language" (puisqu'il faut très longtemps pour faire approuver un nom dans CLDR (des années...) puis ensuite l'importer dans Mediawiki, le déployer dans une version et permettre l'adaptation des modules PHP ou Lua existants et éventuellement nettoyer plus tard les modèle wiki (une fois passé l'accord de la communauté locale du wiki qui peut vouloir conserver les surcharges selon les usages au moins pour éviter de casser des liens vers des noms de pages dépendant de #language, ou du code PHP local, ou de modèles ou modules locaux).

Changer un nom de langue déjà utilisé sur un "gros" wiki n'est pas évident, d'autant que les langues ont de nombreux noms synonymes ou alias, et que les articles et pages peuvent regrouper plusieurs langues ou dialectes dans le même article (différentes sections) ou des articles différents: cette décision est communautaire, et que la classification des langues , variantes et dialectes est évolutive et pas définitive et qu'on découvre des tas d'homonymes et noms ambigus dont la désambiguisation est spécifique à chaque wiki en fonction de son contenu local. Et il y a souvent des controverses sur des tas de noms de langues minoritaires selon l'usage (vernaculaire ou scientifique/technique/systématique), la géopolitique, ou les besoins courants (où on abrège souvent...). Sur les wikis de Wikimedia, les noms doivent respecter une règle de neutralité et de consensus parfois dur à obtenir quand une même langue a des noms "officiels" mutliples (selon le gouvernement, le régime, ou l'entité politique ou sociale et leur perception du contexte historique). Même sur CLDR, on a du mal à trouver les consensus nécessaires à tout changement. Des débats animent aussi l'ISO concernant les noms dans la norme ISO 639, et à l'iETF concernant les noms dans la base IANA des sous-labels pour BCP 47.... Les débats n'en finissent plus si on veut satisfaire tout le monde, alors autant obtenir un consensus local réduit à un seul wiki (qui pourra s'appuyer sur l'usage local dans le wiki lui-même et faire des "mesures" pour voir si ça vaut le coup de changer un nom ou changer une orthographe dans des langues où il n'y a pas d'orthographe officielle ou bien où il y a plusieurs autorités académiques qui ne s'entendent pas entre elles, comme on le voit même en anglais, en chinois ou en espagnol)..

Verdy p (talk)00:56, 15 September 2020
 
Raymond12:27, 16 September 2020

You ask me to review it in GerritWikimedia, I've replied to the notification I received by mail, but GerritWikimedia fails to login me: I have an account, it was created, I have tried resetting the password, it worked, but then the logon screen rejects the logon/password (visibly it has a bug if it does not accept the underscore in my user name, even if it created the account with it!)

Anyway I can reply here that your patch (for LanguageFr.php in Mediawiki's localisation files) looks good for me (from the diff displayed).

You may include a link in Gerrit showing this talk thread with my review here, if you did not receive my reply by mail after the notification I received, or you can copy-paste the previous paragraph.

Verdy p (talk)13:39, 16 September 2020
 

The patch was reviewed and submitted a few minutes ago. Should go live on Wikipedias & Co next week.

Raymond10:54, 17 September 2020
 
 
First page
First page
Last page
Last page