Support

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

Missing space after punctuation in Phabricator:phabricator_ext-core-*/en

Most probably, there where newlines between sentences in the original source code, that were incorrectly stripped while joining lines, instead of being converted to at least a whitespace.

Another typo in the same "phabricator_ext-core" package:

Verdy p (talk)09:25, 14 April 2021

Account problem

Hello, is there an option to regain access to my account User:Spacebirdy. I can verify who I am.

Password reset did not work, I did not get a mail nor in my spamfolder.

Kind thanks in advance, --TheSpacebirdy(talk): I am Spacebirdy 11:22, 8 April 2021 (UTC)

TheSpacebirdy(talk): I am Spacebirdy11:22, 8 April 2021

I've also requested a password reset for the user. Let me know if you still don't receive an email.

Regards,

Abijeet Patro (talk)04:27, 21 April 2021
 

MediaWiki:Contenttransfer-too-many-pages-warning/en and various typos in today's Mediawiki package for content transfers and page merges

Dummy repetitions of the word "pages" in the source English message (inside and outside the PLURAL tags). And other typos in "Contenttransfer" (all are on new resources changed or created in the last few hours):

See:

Verdy p (talk)15:34, 14 April 2021
  • For ContentTransfer: Gerrit:679637
  • For MergeArticle: Developer informed per e-mail.
Raymond06:35, 15 April 2021
 

The word "phase" present in the English source (as well as in the "/qqq" page where it was probably copy-pasted) may actually be probably a typo, used instead of "phrase". I don't see any case where "phase" would make sense for the automated conversion of language variants (i.e. actually characters and phrases) by MediaWiki...

Verdy p (talk)23:13, 12 April 2021

Developer informed per e-mail.

Raymond06:45, 15 April 2021
 

Problem saving links with hardcoded diacritics via the translation interface

Hello. I'd like to report a problem when saving links with hardcoded diacritics (č, ž, š) via the translation interface. The error provided was as follows: "The following parameter is unknown: %8". I have been able to save the link https://sl.wikipedia.org/wiki/Matemati%C4%8Dna_konstanta by editing the source of the message directly. The error occurred in Blockly:MATH CONSTANT HELPURL/sl. Should I file a bug on Phabricator? Thank you for your feedback.

Eleassar (talk)12:26, 20 March 2021
Edited by author.
Last edit: 21:05, 3 April 2021

URLs in basic format are not "hardcoded", they are usually "url-encoded", by transformating each byte of UTF-8 sequences for non-ASCII characters into 3 ASCII bytes ("%nn" in hexadecimal). The leading byte is URL-encoded in "%C2".."%FD", the following 1 to 3 trailing byte(s) are in "%80".."%BF" (the number of encoded trailing bytes depends on the value of the encoded leading byte), so this bug affects any Unicode character that contain any trailing bytes URL-encoded in "%80".."%9F", i.e. one half of all non-ASCII characters, because the Translatewiki.net's UI incorrectly assumes that "%80".."%89", "%90".."%99" (or "%8" and "%9" for actual bytes URL-encoded as "%8A".."%8F" or "%9A".."%9F") are an incomplete scanf/printf placeholder, not correctly terminated by a valid type/format letter (so yes this is a serious bug)

When trailing bytes are in "%A0" .. "%BF", this bug does not occur because "%A" or "%B", in capitals, are not recognized as valid placeholders for C/C++, but the bug would occur if these bytes were encoded using non-standard lowercase in "%a0".."%bf" (because "%a" and "%b" could eventually be placeholders in some C/C++ libraries using extended scanf/printf formatters).

Translatewiki.net actually does not properly check if theses are valid C/C++ placefolder for print/scanf. It does not even know that the message will be used with a C/C++ library, and it also supposes this could be placeholders for other languages (such as DOS-Command or NT-CMD shell variables, or libraries for Java, Javascript, PHP, Python...).

Here you tried "%8D" which superficially looks like a printf/scanf placeholder for a format of length 8 but unknown type/format letter "D"; as this is not recognized, then TranslateWiki assumes this could be also a basic "%n" placeholder for another syntax (a shell syntax for command.com/cmd.exe? or some other programming language of library), and errs because there's no such "%8" placeholder in the original string to translate. What Translatewiki.net does is just making superficial guesses, with frequently false assumptions.

  • One possible workaround could be to link to another redirecting article that does not use these characters in their title (e.g. redirecting the English title).
  • Another alternative would be to not URL-encode non-ASCII characters in the URL, using the IRI syntax supported by modern browsers (and supported also by the MediaWiki parser).
  • You've found the wordaround using the MediaWiki editor instead of the Translate UI (but note that even if you've edited it there, the text cannot be validated in the "review" UI of TranslateWiki, or will resurrect if one needs to point to another URL on the target wiki).

This is a bug of the Translate interface itself: the solution would be to mark the resource to translate as not using the Mediawiki syntax (if this is the case) and containing no C/C++ "printf/scanf-like" placeholder when importing the resource on Translatewiki.net, so that its UI won't perform an incorrect validation check.

As far as I know, the UI of TranslateWiki.net still does not support such flagging (unlike what other common UIs for translations of .po/.pot files for gettext) and just makes some "magic" guess of the format used, assuming it is either using the Mediawiki syntax (where such URL-encoding of URLs is not needed, but where "{}" and "[]" are special-cased for MediaWiki's parser, as well as "$name" for Translatewiki's syntax itself and supported in the Mediawiki API internal libraries, and a few other syntaxes) or the placeholders in C/C++ "printf/scanf" format strings.

Translatewiki.net should not perform such magic guess of the expected format. It creates false positives and does not properly validate all what may be needed for projects. It should support resource-flagging like in .po/.pot translation tools (where the uncompiled ".po" format uses special comment-lines starting by "#," before the resource texts starting by "msgid" or "msgstr"), using some metadata separated from the original string, possibly stored in the "/qqq" doc subpage, or in a dedicated "/qqx" subpage, or using some hidden tag in the source page (like TWN already does when prepending hidden "!!FUZZY" markers in translated subpages that need updates).
I would suggest prepending "!!FORMAT(...)" or "!!{...}" markers is source pages to store that metadata, and possibly as well in the translated pages to make sure that these special markers are in sync with the original).
As well, a project should be able to store such global metadata for their whole message group (to provide some defaults that could be overriden in specific resources using the special marker), notably the programming language that will use these resources, so it will know if printf/scanf format strings are really needed, or if Mediawiki or HTML syntax is expected. This means creating a special page for each message group, containing the group description, contact info, supported formats (including supported plural forms), URL to help/support pages, URLs to their bug tracker and relevant discussions or terminologies for specific languages...
These changes in TWN would make this wiki more universal to better support more projects. The alternative for these projects are to use online translation tools other than Translatewiki.net (most of them are built for .po resources with gettext)...

The alternative would be for Blockly to accept this string in IRI format, natively in UTF-8 (like in the address bar of modern web browsers, or in the Mediawiki parser), documenting that the URL should not be URL-encoded (this would require Blockly to URL-encode that IRI itself, either in its runtime code or during the import of translated resources from TWN to their code repository) and documenting that info in the "/qqq" doc subpage of TranslateWiki.net. However that last alternative requires involving Blockly developers, notifying them, and make them aware of what they can do when importing/exporting their project with Translatewiki.net (only these developers can instruct translators about what they can do).

Verdy p (talk)19:32, 20 March 2021

Hi, Verdy. Thank you a lot for your detailed and clear explanation. The last option would certainly be best but would require someone with the relevant technical knowledge to communicate with developers. Would you be willing to take this on? Otherwise, I'll ask a colleague or will try to do it myself. For the time being, I'm staying with the workaround. --Eleassar (talk) 08:14, 21 March 2021 (UTC)

Eleassar (talk)08:14, 21 March 2021

Feel free to link this talk thread. I would be pleased to see such suggestions implemtend somewhere for improving Translatewiki.net and better support the hosted projects with better communications and reporting with translators, and improved checking and validation of translations.

Verdy p (talk)22:32, 3 April 2021
 
 

I have disabled variables check on this message.

Nike (talk)17:22, 14 April 2021
 

North-Central Dargwa (or Dargin) language [dar]

Hello, here is the Incubator of, as I understood, literary Dargin (Dargwa) language, with the "dar" ISO code. But I couldn't find this language on Translatewiki. I also ask to enable the ability to translate the interface of the Tsudakhar language (the north-central group of Dargin languages). I believe that it has no ISO code, so it could be "dar-tsud" or "dar-cud".

Soul Train (talk)15:38, 12 April 2021

North-Central Dargwa is in Translatewiki./net, but may need to be opened for work: Portal:Dar, and I think it is already appropriate for your demand, even if the "babelbox" incorrectly abbreviates the language name to just "Dargwa", the ISO 639-3 code [dar] is already for the north-central group of Dargwa (or Dargin).

For such dialectal division (actually you propose a dialect within North-Central Dargwa), you need at least 5-letters of extension (and the extension registered in the IANA database, such as [dar-tsuda] or [dar-cudar]) : effectively, all "extang" subtags (3-letters after the primary language subtag) are permanently reserved in BCP 47, and since the publication the reform in RFC 4646, they are deprecated by the publication of ISO 639-3, which stil considers Dargwa [dar] as a single language (but still not as a macrolanguage, because it contains no other single language).

As long as the dialect group is not in the IANA database, you would have to use a private-use extension (starting by "-x-", followed by another subtag using 1 to 8 letters or digits), such as [dar-x-tsuda] or [dar-x-cudar].

So certainly not "dar-tsud", nor "dar-cud", per BCP 47 encoding rules.

Look at: https://glottolog.org/resource/languoid/id/darg1241 (and related entries in The Linguist List), which list these dialect groups (Glottlog assigns its own private-use codes for language groups or dialects, using 4 letters followed by a number; but they are distinct from ISO 639 codes and BCP 47 tags):

  • Megeb
  • North Dargwa
    • Cudaxar (or Tsudakhar) : this is probably the dialect you are speaking about...
    • Gapshin-Butrin
    • Kadarskij
    • Muirin
      • Dejbuk
      • Xarbuk
    • Nuclear North Dargwa
      • Mugin
      • Murego-Gubden
      • Upper Mulebki
      • Aqusha-Uraxi (or Uraxa-Axusha)
        • Akusha (or Akkhusha, Urakha-Akhush, Urkarax)
        • Uraxa

You are refering to the North and Central group of Dargwa dialects, which is exactly what [dar] itself encodes as a single language. Your reference to "Tsudakhar" is just one possible alternate name of the language, used when focusing just on one of its dialects (and not the whole group, i.e. [dar] itself). So your request seems quite confusive.

The "South Dargwa" group is not part of [dar] and refers to two other languages with their own separate codes (in Glottolog and the linguist list, even if they still don't have an ISO 639-3 code for them). South Dargwa languages are still not encoded in ISO 639, most probably due to lack of studies and litterature about them (very few references found in Glottolog and the Lingist list, all quite recent, with only one in 2003, the next one in 2012, the first dictionary Southwestern Dargwa having been published only in 2017 by a single author for the "Sanzhi-Icari" dialect which is apparently its most common one buyt possibly partly covering some other dialects; no litterature is found for the 2nd South Dargwa language, i.e. Kajtak, also not encoded in ISO 639-3).

It is highly probable that South Dargwa languages speakers are/were already using North-Central Dargwa (Cyrillic script) as a lingua franca or for administrative/legal purposes in Dagestan (or some other bordering languages or scripts, like Azeri with the Latin script, or Dagestan and Russian with the Cyrillic script, or Georgian with Georgian script, or the Arabic script for religious purposes), or that informal writings were developed but not widely published, using some phonetic adaptation were needed).
Verdy p (talk)18:39, 12 April 2021
 

Not allowed to translate a message

I tried to translate (edit a translation) a message in the MediaWikicore message group but i get this message: "You do not have permission to edit this page because it contains raw HTML which can be modified to affect all visitors." So how do i translate it?

yardom78 (talk)12:40, 9 April 2021

This is to prevent insertion of malicious code (notably rogue links to bad websites, or dangerous javascript that could steal data from the user).

Usually this occurs when the resource to translate contain raw HTML and the HTML elements or some of its attributes are not completely safe, or is not checked automatically as being safe, or uses an uncommon encoding and is not fully plain-text or the encoding could be used to bypass a HTML security).

You need to specify the link to the message you want to translate, and the language code.

Then submit your translation proposal in a thread posted here, asking for an admininstrator to submit it for you. Your message will also help project maintainers find a better solution to make these resources more easily translatable without the possible security issue. In some projects, the doc page ("/qqq") shows a contact address or link that you can use (possibly on a repository or bug tracker).

Verdy p (talk)14:47, 9 April 2021
 

TheWikipediaLibrary - json-based i18n files in addition to existing gettext

Hi there,

We're working to address a longstanding issue that precluded some of our content from being translatable via translatewiki. We're moving messages from the database into json files over the course of a few PRs, with the idea that these would be picked up by translatewiki. Our first take on this is to do a json file per message type and language, and we've started with the descriptions of our partners who provide resources for the library. You can see here that we've got the descriptions for all partners together in a file for each language. If we move forward with this, we'll add new files for other fields as we take that content out of the database. Before we proceed any further, I'd like to check in to see if this approach is workable on your end, or if we need to organize the data differently. Here's our 1st PR to make this move, so you can see what it looks like currently: https://github.com/WikipediaLibrary/TWLight/pull/654

Feel free to ignore the python, which does the job of extracting the info and creating those initial json files, and just focus on the json.

Feedback is welcome!

Jsn.sherman (talk)16:47, 30 March 2021

Thanks a lot! JSON is generally easier to manage than PO.

One issue I immediately see is that you output non-ASCII characters as escapes, such as "101_short_description": "<p>\u0627\u0644\u0645\u0646\u0647\u0644", etc. According to the convention documented at mw:Localisation file format, it's preferable to use the actual letters and not escapes. Will it be possible to do it? Since humans won't have to deal with these files very often, it's probably not a blocker, although User:Abijeet Patro and User:Nike should correct me if I'm wrong. That said, humans may have to deal with it; for example, sometimes it's too difficult to find things in translatewiki itself and it's more convenient to grep through the source.

Moreover, perhaps you don't need to convert the translated files at all: maybe it will be enough to add en.json and qqq.json and let the translatewiki import/export scripts generate the JSON files with the translations.

Amir E. Aharoni (talk)16:58, 30 March 2021

I agree that using plain UTF-8 would be better (the "\uNNNN" escape can cause problems, as it requires encoding pairs with surrogates from every character in Supplementary planes, and the convention is not universal, as some tools will require the long form "\U00NNNNNN" instead.

As well it is overlong and some tools may not accept leading zeroes, generating ambiguities, unless they use a strictly conforming JSON parser). No such problem with UTF-8, as the only escapes needed are for quotation marks and backslashes inside actual texts, and some ASCII controls like TAB and NEWLINE: this is much simpler to parse anyway even with only a few ASCII exceptions).

You should ensure that the generated JSON is strictly valid to the JSON standard (and not dependant on the old Javascript implementations that had these caveats). You may eventually be lenient when parsing input JSON, as long as there's not any possible ambiguity.

Verdy p (talk)17:20, 30 March 2021

This is all extremely useful stuff. We should be able to do UTF-8 in our initial output and add a json linter to our CICD process to make sure that we can parse the input.

On the creation of files: It's actually easiest for us to create them all no matter what, but we can update to cull the empty ones. We do have a couple of existing translations currently, so it sounds like the ideal process might be to create qqq, en, and then any translations that we do have?

Jsn.sherman (talk)17:46, 30 March 2021

Hi Jsn.sherman

The JSON structure appears to be good and we should be able to process it on translatewiki.net. It will require a small change on our end to read the new JSON file. This change will also be needed if more JSON files are added in the future. You can also use the banana-i18n format for strings in the JSON.

Could we skip the keys that don't have any definition such as: "24_description", "78_description"? These keys appear to be machine generated, can we assume that these keys will not change?

I see that (almost) all the strings in the English language end with "\n". Can this be added programmatically? It maybe difficult for translators to recognize and add this at the end of every translation that they make.

Regarding creation of the language / translation files, only create the language files for which you have translations. When importing the messages translatewiki.net will take care of reading them.

One more thing, translatewiki.net will add a @metadata key to the JSON file. Example: https://github.com/wikimedia/mediawiki-extensions-TwoColConflict/blob/master/i18n/af.json#L2. I hope that this is not an issue.

Regards,

Abijeet Patro (talk)09:03, 31 March 2021

Yeah, I can see that we need to normalize those trailing newlines. Would stripping them out everywhere (instead of adding them) be a good solution?

We can add that metadata key to start with.

And yes, those keys will not change. We may add new ones over time, but won't change what's there.

Jsn.sherman (talk)14:23, 31 March 2021
 
 
 
 

Opened: https://phabricator.wikimedia.org/T279530 to track this

Regards,

Abijeet Patro (talk)14:36, 7 April 2021

Our team was just discussing this some more today and we realized that we may be able to accommodate the content covered by this change with our existing ugettext workflow. Feel free to de-prioritize this task while we verify. We should know in a week or so. I cross-posted this to the phab task as well.

Jsn.sherman (talk)14:48, 7 April 2021
 
 

Activate new language-code: Aruban Papiamento [pap-AW]

Hi!

I'm active in the Wiki goes Caribbean working group and would like to request another language code for Papiamento. We already facilitate Papiamentu ('pap'), spoken on Bonaire and Curacao, but Papiamento, spoken on Aruba, is slightly different in grammer and spelling. Per my conversation with Amir, I would like to suggest to use 'pap-aw' for this variant of the language.

Please let me know if you have any questions.

Ciell (talk)20:04, 24 February 2021

Done.

Amir E. Aharoni (talk)10:03, 4 March 2021

Hi @Amir, Can you help me find this language on translate wiki?

Ciell (talk)09:03, 29 March 2021

Hmm, for some reason it cannot easily be found in the language selector! I'll try to fix that.

In the meantime, here's a direct link that should work as a start: https://translatewiki.net/wiki/Special:Translate?filter=%21translated&action=translate&language=pap-aw&group=core

This link is for core MediaWiki. You can select other components, such as "Visual Editor" in the project selector on the top right side of the screen.

Amir E. Aharoni (talk)10:34, 29 March 2021

Hi Amir, We seem to have the same problem on Wikidata, the language is not visible yet.

Ciell (talk)16:07, 29 March 2021

Please ask Wikidata developers about it.

Amir E. Aharoni (talk)06:17, 30 March 2021
 
 
 
 
 

Please add the Kom language [bkm]

Hi,

I speak the Kom language of Cameroon, and I'd like to translate MediaWiki into this language.

Thanks!

X-Savitar (talk)11:14, 31 March 2021

This is now enabled!

Welcome!

Amir E. Aharoni (talk)15:31, 31 March 2021
 

New project : docs.python.org/fr/

Hi!

We're translating https://docs.python.org in french since around 2000. After using pottle for a few years, since 2015 we only use git & github to translate.

While it works for us because we're willingly using translation to teach git and contribution to open source software, it does not fit everyone: some would just like to translate.

Please note that other languages translators of docs.python.org use various systems to translate: they're all free to choose their process, and we're not going to force them to change, I hope translatewiki has the ability to choose a set of language to translate to.

We do use `.po` files (it's a Sphinx), it's 53034 entries as of 2021-03, 22879 are translated (~43%), and the repo is public on github: https://github.com/python/python-docs-fr, license is CC0, and it change from time to time, mainly on cpython version bumps (yearly), but contributions to upstream docs can occur daily.

We do have a huge proofreading (grammar, spelling, typos, semantic, ...) step before merging a pull request, I would not like translators to use translatewiki as a way to bypass the proofreading step, but I don't know how it can be "integrated".

What I can imagine is: we could take translation from translatewiki and make them PRs so we can review them, edit them at will, before merging, but it would require our modifications to be pushed back to translatewiki to avoid getting out of sync... I don't know what's possible here.

What do you think?

Mdk (talk)15:01, 27 March 2021

Hi Mdk,

Thanks for your interest in using translatewiki.

The translation system at Translatewiki.net is designed to translate software projects into various languages from the source language but as far as I understand it, you'd like to just allow translations to French for https://github.com/python/python-docs-fr

Additionally, I see many .po files in the repo here: https://github.com/python/python-docs-fr which I assume is for individual pages? Everytime a new file is added there we'd have to make some changes to the configuration to read that file on Translatewiki and allow translators to translate them.

Considering the above, and the fact that our UI is not very well suited for translation of long form text, I don't think that translatewiki is a good fit.

To give you an example of how things work, see the following project: https://github.com/WPCleaner/wpcleaner/tree/master/WikipediaCleaner/src/org/wikipediacleaner/translation

Here we read the WikiCleaner.pot file and then identify what strings have to be translated, and allow translators to translate the strings to different languages. You can see the corresponding ".po" files. This is then submitted out to the GitHub repo via a PR: https://github.com/WPCleaner/wpcleaner/pull/61 which the maintainer merges.

Regards,

Abijeet Patro (talk)10:49, 31 March 2021
 

Is translatewiki still updating every Monday and Thursday?

I finished a translation of FreeCol into Interlingue (aka Occidental) last week and have been eager to see it go live but I haven't seen translatewiki drop by GitHub to update here:

https://github.com/FreeCol/freecol

It looks like it last made an update 18 days ago.

Here's where FreeCol is for reference:

https://translatewiki.net/wiki/Translating:FreeCol

Mithridates (talk)06:37, 30 March 2021

Hi Mithridates,

For FreeCol, translewiki pushes the translations out to https://sourceforge.net/p/freecol/git/ci/master/tree/

Your translations are exported out to: https://sourceforge.net/p/freecol/git/ci/master/tree/data/strings/FreeColMessages_ie.properties

I think the GitHub repository is a mirror that is updated once in a while.

Regards,

Abijeet Patro (talk)11:09, 30 March 2021

Ah! So it's a mirror. Thank you very much.

Mithridates (talk)15:31, 30 March 2021
 
 

Rename username

I am requesting to change my username to Tahmid.

Tahmid02016 (talk)09:38, 26 March 2021

Done Done

Regards,

Abijeet Patro (talk)11:14, 30 March 2021
 

username change

Please change my user name to FF-11. When I created my account, I did not know that FF11 wasn't available on Wikimedia because I requested account rename (for privacy reasons) after I created my account here. Now I want to change my name here to match my Wikimedia user name. Thank you!

FF11 (talk)20:45, 25 March 2021

Done!

Regards,

Abijeet Patro (talk)07:38, 26 March 2021

Thank you

FF-11 (talk)11:48, 26 March 2021
 
 

Please make it possible to add suffixes.

Edited by another user.
Last edit: 03:01, 5 March 2021

MediaWiki:Discussiontools-replywidget-mention-prefix/en

Currently, there is a prefix ('@' in English), but no option to add a suffix. In Japanese, there is a custom to add a suffix "さんへ" when addressing someone. thanks in advance.

Afaz (talk)02:50, 5 March 2021

Actually this is to add a "ping" when citing someone, but not necessary to talk directly to that person, this just notifies that person that they are being cited in a mention (it could be a simple quotation from something said or made earlier by that person, or could be an indication given to someonelse to contact the mentioned person):

The suffix would then vary depending if it means "to" ("さんへ" in Japanese), or "about", "from", "by", "for", or if this is just a politeness forula (similar to a "dear") or if it means that this mentioned person is "known", or "recommended", or a "possible" (untested); and it would viable only if the reply in which the mention is made includes that mention in a text in Japanese: in that case the suffix should be part of the response in Japanese, after that mention.

Then if you reply in Japanese and includes "@John" mention, where "John" does not even know Japanese and was cited with his sentence in English, adding "さんへ" will not help John (and readers of your reply may thing that John knows Japanese, when in fact it was just cited).

The only politeness is the (separate) notification that Josn will receive in his own prefered language because he was cited. Others can only know that John was notified. If you expect a reply by John, you would have first to know if he can read your reply, or you would add some text in English just beside the "@John" mention, so that he can read it in the context of your reply, even if the rest of your reply is in Japanese.

So IMHO, this prefix is just a visual indicator and should remain symbolic and generic.

I don't see any better choice than the single symbol "@", which is used by convention, but it could be also an icon or the emoji for a person, possibly tuned by MediaWiki if this is a user name and Mediawiki knows their gender stated publicly by that person in their preference).

If you want to clarify what you mean beside that ("Speaking to X only", "I expect a reply from you X", "thanks to X", "X said to me", "X published...", "X presented...", "X thinks that", "X votes for...", "X rejects...") the text of your reply should clearly state that...

Note that you may need to cite several persons ("@X and @Y approved @Z's proposal"): no "To" meaning implied , so "@Xさんへ and @Yさんへ approved @Zさんへ's proposal" would be very inappropriate ! But the "@" could be an icon or emoji like a "storm strike", or a "male/female/neutral/bot" icon representing the cited user.

Note that you also don't need to use this mention" widget when replying in the same thread to a message posted by that person: in the Mediawiki syntax such replies are just indended, in LiquiThread you just attach a response subthread below the original thread kept as parent. and in that case the link is implicit in that context. Mentions are when a message needs to speak about any other person for any reason and that reason should be exposed clearly.

The "mention" should in fact just generate an appropriate link to that user's profile, that person will be notified (and will reply to your "ping" or not) and others just need to see clearly the generated link that should be usable (so even showing the "@" is not really needed, if the link itself is prominently rendered as identifying a contactable/identifiable person. This maps to what is made in Mediawiki with the conventional Template:@ (alias Template:Ping in many wikis): no symbol, no icon, but a simple way to properly format a link to a user page (possibly hosted on another wiki, or another social site).

Verdy p (talk)03:21, 5 March 2021

"さん" is an honorific title, as is "Mr.".

https://en.wiktionary.org/wiki/%E3%81%95%E3%82%93#Suffix

and "さん"-"へ" means "to Mr./Ms.".

In Japanese, it is rude to refer to another person without adding a suffix.

I understand the "へ" or "to" is a problem, but I feel uncomfortable not using "さん".

Japanese people will not use this feature because they will feel as if they are suddenly being treated rudely on a forum.

Afaz (talk)16:53, 5 March 2021

Yes but this applies only in a Japanese context, and meaningful only to a user speaking Japanese. And the "ping/@" uis supposed to cite anyone, even those you don't know, you are not speaking to directly, and not Japanese. And is the honorific title appropriate for everyone? What is that "user" is not a person, but a bot engine, or an organization, in fact anything that could just have an account? Or is not an adult. Remember that in many cases you'll cite "somebody" without knowing "who" he is:

  • "Hey, @Wikimediaさんへ, when you accept my article?"
  • "This page was last edited by @128.12.13.14さんへ."

Do we need to use some properties of the target "user" account to get some knowledge about how to cite that user ? Isn't the unique name of the account sufficient and appropriate for all contexts? For now the only additional property we have is the gender (if the "user" fills that info in their preferences): male, female, neutral (plus "bot" when they've been authorized). All the other info is in the public user page (if it was created by that user) and their edit history (including votes and talks). There's no such info for IP users (that don't have any personal account but temporarily share some IP account that may have been used or may be used later by someone else): preferences are limited to their browsing session (or the visitor's browser cache) but not stored in preferences of the wiki (eventually a part of these preferences will be transmitted for a specific edit, but Wikimedia restricts which parts of this data can be publicly exposed or stored, except the IP and timestamp for edits in histories which are required for legal reasons as well as to help fighting vandalism, but in most cases it is not publicly exposed, notably not for read-only actions).

The best you can do, if you know you're citing a physical person in a message posted in Japanese, is to add the Japanese honorific title appropriately after the "@user" mention, inside your own text. And it should not be considered rude at all if you omit that title for a person that is not Japanese (that will also won't like to have thir user name transformed or "decorated" in a way that that person cannot even read or understand: that "さんへ" may be interpreted very rudely (as if it was hiding some insult, each time you mentioned that person).

As well you may cite a person without even creating any sentence, e.g. as part of a long list of persons, or in tabular data column or bulleted list: this forced honorici peopel would then spread everywhere and would obscure the list. The best alternative is to use a small custom icon or emoji to replace the "@" in order to explicit to readers of your message that you are citing someone. This symbol makes no assumption of rudeness or politeness. It is neutral. The only politeness or honor will not be in the visible message, but in the notification that this user will receive (on the wiki or via some other channels connnected by that user on the wiki, according to user's own preferences).

Verdy p (talk)11:33, 6 March 2021

The "さん" is an honorific title that can be used regardless of gender, and for inanimate objects and organizations. So it is odd to readers that it is not used in the Japanese UI. For example, Twitter and Facebook also use it for the same function in its Japanese UI.

Sometimes I feel that English and Japanese have opposite grammars. The English word "#999" is written with the Japanese word "999番". When we use prefixes in English words, on the other hand, we use suffixes in Japanese words. When translating an English message board into Japanese, that becomes the biggest problem.

If it's a multilingual UI, I'd like to see the option of suffixes available.

Afaz (talk)14:51, 9 March 2021

Thanks for your comment. So Japanese like to add a magnifying "dear" or "saint" qualifier after every person, organisation, object, or idea ? Is this "さん"/"San" really honorific or just something that is used to explicitly make some precautionary distance between the talker and the absent person/thing that annot reply immediately?

When I look at translations, the "さん" alone becomes "M.", but as a suffix it varies a lot: "Mme", "Mrs", "Sir", or nothing (notably with a pronoun), and in some circumstance the translator needs to add some specific honor like "great", "saint", "grand", (by invention/imagination) and it is often inconsistant across translators. But when I look at postal addresses in Japan, or entries in diaries, it is never used. Same thing in simple lists, or nomintaive citations outside any sentence or given opinion, or in signatures. I don't think it is really honorific, I could just call that a contextual "particle" with no real meaning except to differenciate what someone says for himself from someone/something he's just citing: that's a form of isolation, a "wall" or "guardrail" around the cited person/thing.

Much like if we used quotation marks around the cited person/thing (quotation marks can be marked vocally by a difference of tone/stress or some pause, but here it seems that Japanese uses a specific particle word, in order to avoid any change of tone (which would alter the meaning, as Japanese tone is strongly semantic, even if it is not written when using kanas)

That's really odd...

Verdy p (talk)16:56, 9 March 2021
 
 
 
 
 

Rename reuqest

Hello, I request that my username be changed to ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ so that it will be same as my Wikimedia account username. Thank you.

AVSmalnad77 (talk)09:17, 21 March 2021

Done Done

Raymond12:58, 21 March 2021
 

help when 'Plural' syntax is not accepted

Hi all, concerning following message => https://translatewiki.net/w/i.php?title=Special:Translate&showMessage=strings-profile_rephotos&group=ajapaik-app&language=fr

I think a parameter $1 is missing as for the plurality but it is rejected saying it must be {PLURAL| ...

{{PLURAL:$1|zero=Vous n’avez encore fait aucune rephoto|one=<b>1</b> rephoto|<b>%1$d</b> rephotos}}

I cannot find the correct syntax. I checked it is ok with template => https://translatewiki.net/wiki/Template:PLURAL/doc but cannot succeed; help please. Seems as if the original message was wrong (?). Thanks.

ChristianW (talk)12:12, 23 March 2020
Edited by another user.
Last edit: 23:48, 19 March 2021

As per CLDR data, French has only two plural forms. So the below should be enough,

{{PLURAL|one=<b>1</b> rephoto|<b>%1$d</b> rephotos}}
Abijeet Patro (talk)12:57, 26 March 2020
 

The source string was just fixed yesterday by Ajapaik developers. The zero version is now a separate message.

Nike (talk)13:03, 26 March 2020

Sounds good now; in french 0 or 1 follow the same way, 2 and over start plural, so according to the number of books on the shelf you say

Il n'y avait aucun livre   sur l'étagère. 
Il   y avait zéro  livre   sur l'étagère.
Il   y avait un    livre   sur l'étagère.
Il   y avait deux  livres  sur l'étagère. 

Thanks; done.

ChristianW (talk)21:04, 26 March 2020

You're lucky in that someone is even willing to listen to you. I've been trying to correct the Portuguese plural for years to no avail, despite the fact that even CLDR agrees with me. The first thing that they usually throw back at you is that you need to convince CLDR. Once you point out that CLDR is already correct and convinced, and agrees with you, and MediaWiki is wrong, they'll push onto you the job of correcting it yourself.

Hamilton Abreu (talk)02:22, 28 March 2020
 

The "zero" case can be treated specially in French: if you use a number in the translation, treat it as singular only.

But like in English, the message can also use the negation if the number is spelled in a sentence like "Il n'y avait aucun livre" or "il n'y a pas de livre" where sometimes such negative form implies a plural for the noun, depending on the meaning of the noun: "Il n'y a pas de livres" is also correct with the plural, applicable only to enumeratable things, and means "not one and not even more than one").

So the "zero" case may be added optionally to any translation, in addition to the 1st (singular) and 2nd (plural) forms.
This "zero" case should not be used at all if the number is displayed with digits as "0", which must be treated with the singular.

For some sentences where the number is a small integer quantity, you can specialize the translation to spell that number instead of formatting it with digits. This would apply only if the maximum number is small and spelled as a single word (0 treated specially with the "zero" case, or other integers from 1 to 16, or one of 20, 30, 40, 50, 60, 100 and 1000, each using a special case for these values and nàot depending on the default plural rules even if grammatical French rules still apply to these numbers: 1 may be special-cased but the translation should use a singular form for nouns, adjectives and verbs, all other special cases should use the plural form); all other values should be formatted using digits and the standard French plural rules:

  • if abs(n) <= 1 (including n=0.5 or n=0 or n=-1), then use the singular (1st form, used by default)
  • if abs(n) > 1 (including n=1.5 or when n is infinite), then use the plural (2nd form if it's specified, otherwise display the 1st mandatory form)
  • if n is unknown/unspecified, then use the plural (2nd form if it's specified, optional otherwise display the 1st mandatory form) without writing any number

Note that the 2nd form is also optional in French translations, as it may be the same when the form is grammatically invariant in some cases. For example,

  • "1 face" vs. "2 faces" (because the noun "face" has no mute mark of the plural in its singular form, you need a second form to mark the plural)
  • "1 dos" vs. "2 dos" (because the noun "dos" is already terminated by a mute "s" which then remains invariant in the plural)
  • Such cases with invariant grammatical plurals also occur in English (but much more rarely than in French, as English will most often repeat the 's' by inserting an extra non-muted 'e' pronounced as a schwa before this added 's' for its semi-regular forms of plural marks: "1 boss" vs. "2 bosses", but in French the borrowed term boss would remain invariant: "2 boss" because the French term "bosse(s)" is completely unrelated).
  • Invariant grammatical plurals also occurs in almost all languages with abbreviated units of measurement ("1 m" vs. "2 m"), and some translations may prefer using common abbreviations with a single translated form, rather than translating several plural forms: "1 meter" vs. "2 meters" in English, "1 mètre" vs. "2 mètres" in French.
  • Marking the plural in French for terms borrowed from other language is variable and depends on usage: you may use the normal French rules for derivation ("1 pizzaïolo" vs. "2 pizzaïolos", this is generally preferred) or the derivation from the original language ("2 pizzaïoli" from the Italian term, except this is generally not acceptable here as the orthographic term was already modified in French with the diaeresis in the singular, and this singular form should be the base for forming a regular plural), but the choice of marking the singular or plural must still use the French rules ("0 pizzaïolo" : must be singular). Another example (more acceptable): "2 misses" (irregular plural form taken from the English noun "miss(es)" for a woman borrowed as is, but not that we'll still write "0 miss" in French with the singular form chosen, vs. "0 misses" in English with the plural form chosen).

But if you add some other terms in the translation, you may see the difference of plural form in dependant adjectives or verbs that require marking the singluar or plural distinctly:

  • "1 dos courbé" vs. "2 dos courbés" : now you need the two forms in translations
  • "1 dos se courbe" vs. "2 dos se courbent" : now you need the two forms in translations
  • "1 dos à courber" vs. "2 dos à courber" : one form remains sufficient in translations; the verb "courber" is invariant as an infinitive as it has no subject with which to match a number); if you translate the second form, it should be identical to the 1st form intended for singular, also used by default.

If n is a rational fraction, and the full fraction is specified as the explicit numeric values of the numerator and of the denominator (like "⅘") the plural is marked in French only the term for the denominator but then the unit that follows is using the singular form when it is preceded by the preposition "de" according on this fraction: "½ litre" but "10/20 de litre", "¾ de litre". The French rule is:

  • if the absolute denominator is 2, don't use the preposition, but match the plural with the absolute numerator; the French term for the denominator "2" is the adjective "demi-" which is invariant before the noun it qualifies and attached to it by an hyphen: ("demi-" is prefered to the alternate ordinal "2e(s)=deuxième(s)" which is also possible and whose plural varies according to the numerator, but which is almost never used)
    "½ litre" = "1 demi-litre" (= "10/20 de litre" = "10 vingtièmes de litre"): the denominator is 2, so no preposition and then the numerator 1 is singular, so after "demi-", the "litre" will be singular.
    "3/2 litres" = "trois demi-litres": the numerator is 2, so no preposition and then the numerator 3 is plural, so after "demi-", the "litres" will be plural.
  • if the absolute denominator is not 2, use the preposition "de" before the singular noun;
    • the fraction may be spelled using ordinal numbers as nouns for the denominator: "3/12e(s) de litre" or "3 douxièmes de litres" ; when the denominator is spelled, it takes its plural form according to the numerator); The form "3/12e(s)" with an explicit ordinal mark including its own plural mark is needed (either use a suffix preferably in superscript, or use a more compact typographic fraction like "¾" without any suffix and without even any preposition "de" before the noun); the terms for fractional ordinals however are a bit different from rank ordinals, for these two denominators 3 and 4:
      "3s" or "tiers" (numerically invariant) for fractional ordinals, instead of the normal ordinal "3e" or "troisième" only used for (invariant) ranks.
      "4t(s)" or "quart(s)" (numerically variable according to the numerator) for fractional ordinals, instead of the normal ordinal "4e" or "quatrième" only used for (invariant) ranks
    • the fraction may also be spelled using a cardinal number for the denominator and if so the noun after it will follow the denominator: "3/12 litres"="3 sur 12 litres" (plural according to the denominator 12), or better, if you can, the units may be placed before the numerator from which it will match its plural: "3 litres/12"="3 litres sur 12" (plural according to the numerator 3)
    • This means that "¾ de litre" = "3/4ts de litre" = "3 quarts de litre" is correct (litre is singular after "de"), but also "3/4 litres" ("litres" is then plural according to the numerator 3): you cannot use the typographic "¾" and the legacy "3/4" interchangeably. But you can use the typographic "¾ de" and the legacy "3/4 de" interchangeably (with a singular noun).

These rules are almost identical in English (using the preposition "of") which also has specific terms for a few common fractional ordinals (always "half"/"halves", rarely "tier(s)", frequent "quarter(s)") used instead of ordinals for ranks (never "second(s)", most frequent "third(s)", frequent "fourth(s)", ).

However, using rational fractions is still not supported as distinct cases in translations for now, because there's no key for them. They may be used only for specific fractions that are exact as decimal numbers (fractions whose denominator is decomposable in a product of powers of 2 and 5, for which the plural case key would its decimal value as a single non-integer with a limited precision (0.25, 0.5, 0.75, 0.125, etc.); this could work with some translation libraries offering the support for non-integer values of keys n, or offering support for rational keys with the form m/n.

Verdy p (talk)00:28, 28 April 2020
 
 
 

New project request: EDTF PHP library

We are developing an EDTF implementation in PHP for the Luxembourg Ministry of Culture. One part of this library allows turning an EDTF string into a more readable natural language version. We already have preliminary support for multiple languages, and would like to use the message system of TranslateWiki to support more languages.

The library is at https://github.com/ProfessionalWiki/EDTF.

TranslateWiki can get write access on this repo.

Will get an open source license soon. I know this is a TranslateWiki requirement. We are waiting on confirmation from the Ministry.

You can see string construction at https://github.com/ProfessionalWiki/EDTF/blob/14b8a71e25444a25a5f0f3eda628be551fd4871e/src/Humanize/Languages/EnglishHumanizer.php. We'd replace this with a message (string key plus arguments) system like MediaWiki has if we get TranslateWiki support.

Jeroen De Dauw (talk)16:19, 9 February 2021

Do file a Phabricator task per the template in Translating:New_project when you're ready. Do note that inflectNumber (and maybe other code too) needs to be made language aware. You may want to look at CLDR data to see how much of that can be used to solve this.

Nike (talk)11:34, 11 February 2021

Thanks!

Any thoughts on how to avoid having `inflectNumber` in our code to begin with? Ideally we'd be able to use some PHP library that we just give the message key and some arguments, and that then takes care of it, including using the translation files from TranslateWiki in the repo.

Jeroen De Dauw (talk)17:39, 12 February 2021

Looks like it is now suppored by twn: https://translatewiki.net/wiki/Special:Translate/mwgithub-edtf. Cool and thanks!

[[kgh]] (talk)16:43, 19 March 2021
 
 
 

Hello, who can help me in renaming of my account from "Გიო ოქრო" to "გიო ოქრო"? Thanks.

Გიო ოქრო (talk)21:37, 11 March 2021

Something seems to be wrong the rename:

16:06, 16 March 2021 Raymond renamed user Გიო ოქრო (229 edits) to Იო ოქრო (https://translatewiki.net/wiki/Support#Renaming_58728)

I tried to remove the leading Ი but this character is still there and the first real character ი was removed. No idea how to solve this issue.

Raymond15:38, 16 March 2021

That problem was also in ka.wiki, see Phabricator task. Now it has been rectified.

Იო ოქრო (talk)09:31, 17 March 2021

Ok. Do I understand correct, that Გ is the uppercase letter of გ? Looks like my computer does not have an up-to-date font for Georgian as I see Გ as placeholder character only :-(

Raymond14:52, 17 March 2021
Edited by author.
Last edit: 20:33, 17 March 2021

Actually modern Georgian is unicameral. Georgian has historically used at least 3 major script variants (which in earlier versions of Unicode were merged into a single one and incorrectly encoded as if it was bicameral with two variants; even if at its original it was unicameral and using only one variant).

There is however some limited use where 2 script variants may be used simultaneously, but normally NOT in the same word (it's like the upright versus italic variants in Latin, that you normally don't mixup to create case distinctions).

At some past period, there's been an attempt to use two variants as if the script was bicameral, making one of the variants "capital", and the other lowercase. This was an error.

Actually you should NEVER convert any lettercase in Georgian, letters should preserve their existing case in the 3 existing major variants. But outdated softwares still do this conversion to generate some "titlecasing", which is wrong for Georgian as it will mix the 3 variants (that are actually 3 distinct alphabets, not exactly and fully equivalent). So "Გ" is NOT the uppercase letter of "გ"; these are just semi-equivalent letters in two variants of the script. In the modern Georgian use, you can perfectly use only one variant for everything in your text;

But a second variant may be used to emphasize text (not to create case distinctions), just like you could use smallcaps in Latin in a paragraph of text, or use an "allcaps" style for monumental inscriptions and small extracts of text (but note that in Latin, you loose some text distinctions; the same occurs in Georgian because converting from the modern to the historic "capital" variant is also lossy for a few characters of the alphabet).

Mediawiki should not then remap any Georgian letter for titlecasing (i.e. the first character of pagenames), even if these characters are sorted at the same position for the primary collation level): these letters are still distinct, but the distinction is NOT a valid lettercase distinction.

There are some informal use of the Georgian script as if it was a bicameral script (or even tricameral!), but this is informal. Such transforms are in general lossy and invalid if they are automated. The best way you should look at the Georgian script is "as is" it actually was 3 distinct scripts M, A and N; but another view of it considers it as having 2 major scripts (only A, or mostly M plus some A; mostly A plus some N);

  • [Geor] (Georgian): Mkhedruli + some (Aso)mtavruli, or just Mkhedruli (modern use only). Mediawiki casemaps M+A as it it was bicameral (this is deprecated: a M-only text is correct, an A-only text is not modern Georgian).
  • [Geok] (Khutsuri): Asomtavruli + some Nuskhuri (Nuskhuri is normally never used alone); this is an old historic use (A+N, or just A for monumental use only).

The question of whever Georgian is really bicameral is still debated (this depends on orthographic conventions that have still never been resolved definitely): this is the same situation that occured in the past for Medieval Latin, or Medieval Greek, before bicameral lettercase were considered as important distinctions with string distinctions allowing the same word to mix the two cases under strict conditions (and then conversion under weak/lossy conditions).

There's a comparable situation in Japanese which is written with 2 distinct Kana scripts (Hiragana and Katakana) which are not really equivalent (one of them is more lossy than the other), and that uses a third script occasionally (Kaji sinograms): converting *automatically* between Hiragana and Katakana is invalid, even if some letter pairs collate at the same primary position (in a sorted list or for plain-text searches).

Raymond, what you did was clearly wrong: you removed the first letter "Გ", the user asked you to change the first letter "Გ" from one Georgian alphabet variant to "გ" another variant. Then the second letter was incorrectly capitalized (and here this is a bug of MediaWiki that should NOT capitalize this "ი" letter into "Ი").

In fact as long as Mediawiki considers Georgian as a true bicameral script (based on how the script was initially encoded in Unicode, then extended later to add a third historic alphabet now considered as part of a separate "Geok" script for ISO 15924) the two letters "Გ" and "Გ" (that are "case-mapped" by Mediawiki using the deprecated Unicode casing rules) should have caused the request to NOT be honored.

You should have not touched this username at all because Mediawiki still considers they are equivalent when ignoring case (and there's still no way to avoid the "promotion" of the "გ" initial onto "Გ" in page titles).

Instead the user could have modified its user page "User:Გიო ოქრო", using "{{DISPLAYTITLE:User:გიო ოქრო}}" as a valid way to override the incorrect forced capitalilisation made by MediaWiki.

Verdy p (talk)19:53, 17 March 2021

"Raymond, what you did was clearly wrong: you removed the first letter "Გ",..:"

Yes, this is what I understand no. Გ looks like a kind of control character which should be removed.

@Გიო ოქრო: I can try to rename you back to "Გიო ოქრო". But I see no chance to rename you to "გიო ოქრო" because MediaWiki converts every first character of a page, even a username, to uppercase.

Raymond20:10, 17 March 2021
 
 
 
 
 
First page
First page
Last page
Last page