View source for Thread:Support/Help test the terminology gadget!/reply (15)

From translatewiki.net
Jump to navigation Jump to search
NoteSupport Problems? Questions? Suggestions? Write your message below. — See also the FAQ or try to catch us in IRC or in Telegram.

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
Previous page
Previous page
Last page
Last page

Add "[skip ci]" to MantisBT commit messages

Hi Guys,

Would it be possible, when translation updates are pushed to our GitHub repo, to add [skip ci] to the commit message ?

This would avoid having TravisCI running the test suite over text-only changes, which are extremely unlikely to cause build failures, unnecessarily using up our build credits [1].

Thanks in advance !

[1]: at the moment, translatewiki.net commits account for about 14% of our credit consumption.

-- Damien14:14, 17 May 2022

You could also reschedule the pushes to GitHub to occur less often (I.e. give a few days of delay, a time usually needed for reviewing messages and fixing some typos).

You may as well create a separate temporary import branch in GitHub for making this review yourseld and allow fixing them in Translatewiki. Once the basic quality test passes, you can import them from the temporary branch into the main branch for integration and complete tests by just creating a patch directly inside GitHub. As well you can schedule languages from the temporary branch to your main development branch.

Finally if there are new messages in TWN that concerns only a separate branch of MantisBT which is still in development and testing, you may not need all languages at once, but a few needed for your development tests. Identifying messages needed for a beta branch may also be documented in /qqq doc pages. As well you may need to keep a separate import for messages needed for older branches that are still supported (and this can also be documented in /qqq pages).

But in my opinion, TWN should allow messages to be marked with tags identifying versions or branches for which they are needed (this is already a problem as well for Mediawiki messages, whose cleanup requires lot of searches and is for now very complex, so we have now lot of messages in TWN that are no longer relevant for a supported version)

This also requires defining a naming sheme for message identifiers, and make sure that messages that are modified in one version to another remain compatible (notably when there are placeholder variables, and you change the set of variables or sometimes their order, or their meaning or possible values, you need a new distinct message ID to be translated separately: one message will be for one older branch, another for the newer branch, and you need to find a way to manage these version-dependent or branch-dependent message IDs).

Some projects in TWN use an "opaque" MD5 or SHA checksum of the text in the source message but this does not allow tracking versions/branches easily, unless you maintain a database for message signatures needed for each supported version or branch (including those in older releases for longer-term support).

Verdy p (talk)14:40, 17 May 2022

Thanks for your suggestions, but the fact remains that whenever a commit is pushed to Github (even if it's less frequent), an unnecessary build is triggered.

Moreover, we only get translation updates for our master branch, and we don't (need to) validate/review translations so the other comments are not relevant for us.

-- Damien15:53, 17 May 2022

You need some review: translations may not be compatible if there are missing variables or incorrect formats causing unexpected "breakages" within some UI language. Normally TWN attemtps to make most of the format validation. But still if you've got multiple stable releases maintained, they will need translations (or corrections) in parallel branches, with separate messages (if their format is not compatible, such as changes in placeholder variables or changes in format, such as addition/removal of HTML tags, or addition of support for more plural forms).

But if importing messages in your GitHub project causes a complete rebuild, may be you should split your project by putting translated messages in a separate subproject, where the main project would not depend on it, except when running a script to build a full installation for a release from the core subproject and the i18n subproject.

The core project would then just need the base English messages and no other messages, or just a subset of translations for specific messages and specific languages (such as Arabic or Hebrew to test the Bidi layout, or Pseudo-Arabic actually in English where capital Latin letters are treated as RTL, and lowercase are in normal English, like in examples used for the CLDR documentation and tests)

Building the whole application package with all i18n can then be scheduled at a lower rate (only manually). i18n message can be updated frequently (without causing unnecessary rebuilds of the core project or the complete app apackage, and you also no longer have a limit on the rate of edits for the core project in English.

As well you should verify your "makefiles" (or building rules): it probably has incorrect dependencies not correctly tuned, so that any change anywhere (not just in 18n messages) causes the complete rebuild. And I don't see how adding a "[skip ci]" tag on TWN would avoid rebuilding the whole project in the main bracnh on GitHub after each message import.

Verdy p (talk)16:19, 17 May 2022

I don't understand where you're coming from. MantisBT translations have been managed like this, without any issues, for at least as long as I've been part of the project (i.e. since 2010), so I see absolutely no reason to change our workflow.

As for

I don't see how adding a "[skip ci]" tag on TWN would avoid rebuilding the whole project in the main bracnh on GitHub after each message import.

This is just how TravisCI works; if this string is present in the HEAD commit's message, then the build is not triggered. See https://docs.travis-ci.com/user/customizing-the-build/#skipping-a-build

Also, to clarify, the TravisCI "build" process I'm talking about just runs our PHPUnit tests, it does not actually "build" anything.

-- Damien08:21, 18 May 2022

Yes but this filter only appliues to commits in the "HEAD" branch in GitHub.

You are not required to import every incoming translations from TWN directly to the HEAD: there can be intermediate branches, and the final commit of these intermediate/progressive branches (which could include many minor updates, rapid reverts, typo fixes, and in many languages...) to the HEAD can then be delayed (e.g. once a week, if they pass the minimal test of format). These weekly integration of these branches to the HEAD won't even need that filter in that case.

I think it is a bad idea to apply imports applied by automated import bots directly into the HEAD of any Git project, when these translations were not made by developers but by translators that may not be aware of all possible problems (that may still need to be fixed, and possibly better documented in "/qqq" message subpages in TWN, so that these bugs won't be repeated). Remember that TWN will not necessarily detect all problems, your TWN import tools should problably perform additional validation, and this is easier to do in a separate branch, instead of just the HEAD used for all the rest of the development of supported versions.

Verdy p (talk)11:23, 18 May 2022
 
 
 
 

We don't currently have the ability to change the commit message per project [1], but we would like to find a solution. Are there any other ways to achieve the same end result?

Nike (talk)07:20, 20 May 2022

As long as l10n changes are pushed directly to the master branch, I can't think of any way to bypass the TravisCI builds externally.

One alternative solution could be, as Verdy_p suggested, to have TWN push the changes to a separate branch, that we could exclude from automatic builds (blacklist). We would then have to manually merge changes into master. Maybe a Pull request could be opened to notify us that new translations are available. That involves some extra work on our end to manually merge changes, so it's a regression compared to the current situation but I guess we could adapt and live with that.

Another option (just brainstorming here) - assuming there is some existing API allowing that, we could pull changes and automate this on our end but that sounds like a lot of work.

Considering that the [skip ci] option is quite standard nowadays, and supported by most if not all of the main CI providers including GitHub Actions, Gitlab Pipelines, CircleCI and TravisCI, I believe that the best solution would be to implement some project-specific flag in the TWN config (repoconfig.yaml ?) to control whether [skip ci] is tagged at the end of the standard commit message.

Not being familiar with how that works internally, I have no idea if that's feasible or how complex it would be to implement.

-- Damien09:23, 22 May 2022

Isn't there also the option to change the scheduling for exports from TWN and imports to Git? Projects have the option to define when they occur. May be the current scheduling is troo frequent (twice a week by default) and could be changed (once a week for example, so that you'll also reduce the frequency of automated builds in Travis, if this becomes now too costly).

Using branches for imports in Git IMHO is the best solution if you want to preserve the frequency (and possibly even increase it, e.g. each day) it does not prevent setting up another Git-specific bot if needed to sync that branch to the master, witrh a bot that you can schedule as you want, pause and restart when needed, for example pausing it when you're stabilizing a version of your project for a coming release)

Verdy p (talk)09:32, 22 May 2022
 
 
 

Broken empty message

I tried to delete the spam (?) from MediaWiki:Fileimporter-cantimportfileinvalid/ar, but just emptying the translation apparently broke the so called Banana checker on Gerrit. How to deal with situations like this?

TMg (talk)14:53, 21 May 2022

I deleted it. It should fix the problem.

Amir E. Aharoni (talk)18:27, 21 May 2022
 

Translation search and memory upgrade and disruptions

We are planning to update Elasticsearch on our server on 11th May, 2022 at 10ː00 AM UTC (Please see update). Elasticsearch powers the translation memory and search.

We expect this process to take a few hours to complete. During this time, there will be some disruption to the translation memory and search.

See the following Phabricator task for more details.

Regards,

Update: We've postponed this upgrade due to the following issue found during testing.

Update - 17th May, 2022 1230 UTC - The update is now planned on 18th May, 2022 at 1300 UTC

Abijeet Patro (talk)14:37, 9 May 2022

The update is complete.

Nike (talk)17:37, 18 May 2022
 

Request for Campidanese (sro) qualification

The Wikipedia project in Sardu campidanesu - Lìngua sarda campidanesa - Lingua Campidanese (Wp/sro) [1] has already many pages and many categories, but it has a problem: the portal of translatewiki [2] contains an error, because there is the writing sro: Logudorese Sardinian, sardu logudoresu. Logudorese (src) is another language of Sardinia and has its own portal on translatewiki [3], where there is the error that refers to Campidanese; but Logudorese does not yet have a wikipedia project (Wp/src). Campidanese is not an enabled language [4] and a request is now made to enable it. Thanks in advance for your attention.

F Samaritani (talk)19:59, 20 March 2022

Hi, I can do the configuration, but I have a few questions:

  • Other than the Wikipedia Incubator, are there any books or websites in this language?
  • Are there any books online about this language, for example a grammar book or a dictionary?
Amir E. Aharoni (talk)07:18, 29 March 2022

See:

  • Spoken L1 Language: Campidanese Sardinian, [1]
  • Vanrell, Maria Del Mar; Ballone, Francesc; Schirru, Carlo; Prieto, Pilar, Sardinian Intonational Phonology: Logudorese and Campidanese Varieties, [2]
  • Grammatica sardo-campidanese, [3]
  • OLAC resources in and about the Campidanese Sardinian language, [4]
  • Sardinian, [5]
  • Size and vitality of Campidanese Sardinian, [6]
F Samaritani (talk)06:03, 13 May 2022

OK, this is deployed. I've put a link of important projects on your user page, User:F Samaritani. I recommend starting with "Most used / Most important".

Amir E. Aharoni (talk)13:40, 18 May 2022
 
 

The portals and their classification did not have any error, but a template giving language names had entries for "src" and "sro" copy-pasted and then swapped; this is fixed (no change in portals or categories that were already correct); initially there was no language name shown at all in portals, only language code; and there was no confusion of codes in these portals. So this was a display problem created when those missing names were added. Now it is fixed.

Note also that I removed the "disabled" status for Campidanese [sro] only; (Logodurese [src] is still disabled, as apparently it still refers to the default language used in existing translations made for the Sardinian [sc/srd] macrolanguage)

The Sardinian macrolanguage [sc/srd] in ISO 639-3 also covers Sassarese [sdc]; it also covers Gallurese [sdn] which is spoken in Northern Sardinia but is a variant nearer from Corsican [co/cos] than from the 2 other Sardinian languages; Sassarese is more distant as it is a Gallo-Italian language inherited from sailors and troups coming from Genova, so it's nearer from Northern Italian languages, like Ligurian, Piedmontese, Lombard, and Venetian; Corsica was also invaded by Genovan troups, but not for long enough so it kept its Southern Romance features which still exist in Gallurese). Not all linguists agree on that for their modern evolution: Sassarese progressively adopts now more Italo-Romance features (including from Italian, and Logodurese Sardinian) but tends to become now more distant from Corsican, even if there's still good mutual understanding on both sides of the Bonifacio channel. However standard Corsican is still used in Corsica (along with standard French for official use) because it has a strong regional and cultural support, while Sassarese in Sardinia is supplanted by other Sardinian languages (and standard Italian for official use, which is the most serious threat to all Sardinian languages); the links between Sassarese and Corsican is weaker today because there's much less use by sailors across the maritime channel (with a drastic reduction of fishing and the cretion of natural maritime parks that limit the navigation; so the essential maritime links are commercial for tourists or freight, and most tourists or transporters don't speak Corsican or Sardinian, but instead French, Italian or English).

Verdy p (talk)14:15, 18 May 2022
 

Please Help me

There are many books in Nogai with latin alphabet but still the latin alphabet is not inserted???

TayfunEt. (talk)05:15, 11 May 2022

Please stop creating multiple threads about the same issue. Continue the discussion where it is already taking place instead of creating a new thread. Thank you.

Jon Harald Søby (talk)14:03, 13 May 2022

The problem is @Amire80: is not answering to me.

TayfunEt. (talk)04:40, 16 May 2022

Please be patient. I need to check these documents. It takes time.

Amir E. Aharoni (talk)07:04, 17 May 2022

I'm very sorry for my impatience... And I have a question, in ugwiki is the Main Page name «ئۇيغۇرچە ۋىكىپەدېە» wich means "Uyghur Wikipedia", but it needs to be «باش بەت» (Main Page). Do you know how I can change this (I did look to the translations, there was written «باش بەت»)?

TayfunEt. (talk)14:36, 17 May 2022

Please don't mix unrelated issues. This should have been in a separate thread. But the main page of any Wikipedia edition cannot be changed isolately without discusing it with their own local community (on the associated talk page), and then proposing a change, and sometimes submitting also a formal request in Phabricator to Wikimedia administrators (to change the protected redirects from "Main Page"): this main page is a very sensitive page.

But I agree that the main page by default in MediaWiki should not name or reference "Wikipedia", as there are also other non-Wikipedia wikis (including outside Wikimedia) that also need their "main page". But nothing prohibits a specific wiki to override locally this default (so the Uyghur Wikiepedia may still override locally this default to «ئۇيغۇرچە ۋىكىپەدېە» ("Uyghur Wikipedia") if they wish it and decide it locally, and then the default translation of the main page name made in TWN (independantly of any wiki) will be ignored in imports. Such wikis can block these imports from TWN by blocking edits of the main page and blocking this page from being moved/renamed or affected by automated imports from TWN: the Uyghur translation from TWN will fail to be imported, as expected, because of this local blocking. Note also that the default translated "Main page" name way still be used locally in their main namespace, but as a local redirect to another locally prefered page name also in their local main namespace.

Verdy p (talk)14:55, 17 May 2022
 
 
 
 
 

Help test the terminology gadget!

How it looks when you hover a term with a translation with the gadget turned on.

Hello, everyone! I'm excited to share that I am almost finished with a script I've been working on for the past month, called the Terminology gadget. What it does is that it lets translators define translations for English terms that are stored in a central place, and will be shown to others who translate into the same language. You can read more about how it works on Project:Terminology gadget.

I am hoping that this gadget can be enabled as a default gadget for everyone on Translatewiki, but before we can consider that, I need help with testing it to see that everything works as it should. So if you would like to help test it, please enable it in the preferences, and let me know of any bugs/errors you find, or if anything is confusing/difficult to use.

I'm excited to hear what you think!

Jon Harald Søby (talk)23:32, 25 November 2021

Bug report: Nothing happens for creating aliases. Steps to reproduce:

  1. Visit Portal:Zh-hant/terminology.json
  2. Click "Add term"
  3. Fill "English term" with "settings"
  4. Check "This is an alias for another term"
  5. Select "setting" for "Alias for"
  6. Click "Save"
Xiplus (talk)04:17, 26 November 2021

Thanks for testing it out, Xiplus! This should be fixed now. Let me know if you find something else. :-)

Jon Harald Søby (talk)07:39, 26 November 2021

I really like the "animation" when you click on the word. However for the moment i don't found any bug.

Ajeje Brazorf (talk)11:36, 26 November 2021
 
 

Not sure if the Translate Extension already has such a feature, if that is not the case, your work or the concept at least should definitely get upstreamed! By the way, I believe the option of creating project-specific terminology entries to be worthy of consideration.

Ricordisamoa21:25, 27 November 2021

It doesn't, I wouldn't have spent all this time making this if it did. 😜

Yeah, I thought about making project-specific terminology an option when I first started, but it adds a whole extra layer of complexity, not only in the script (where it wouldn't actually be that complicated), but also for those entering/using the definitions in the script. So I think it is better to handle that in other ways, e.g. by specifying in the definitions that "this translation applies to X project or in Y context".

Jon Harald Søby (talk)22:44, 28 November 2021

Hi, I found a bug with this gadget: the cross to quit doesn't work.

Ajeje Brazorf (talk)20:57, 1 December 2021

@Ajeje Brazorf: Ah! Where exactly? There are a few different crosses. The ones I checked just now work like they should.

Jon Harald Søby (talk)22:13, 2 December 2021
 
 
 

Another bug report: $VARIANT doesn't work in the "Usage notes" field. We also want this to work so translators can see notes in their preferred variant.

Tranve (talk)09:32, 4 December 2021

@Tranve: Where/on what page doesn't it work? I only see $VARIANT being used in usage notes on the terms "set" and "setting" in Portal:Zh/terminology.json, and when I checked those in Portal:Zh-hans/terminology.json and Portal:Zh-hant/terminology.json, as well as on [1] for both variants, it seems to be working like it should.

Jon Harald Søby (talk)01:15, 6 December 2021

Weird, now I can't reproduce this problem either, and I have no idea why... Maybe we should mark this issue as fixed now and continue discussion if it arises in the future.

Tranve (talk)13:30, 6 December 2021

@Tranve: Cool! Do you happen to remember how the error manifested itself? Did it show the wrong variant, or something else? If it showed the wrong variant, it could have happened if you were on Special:Translate and switched between hans and hant in the upper right-hand corner. I need to figure out a way for the script to reload when the users switch language (there is already a thread about that on the gadget talk page, but it's not really an easy fix).

Jon Harald Søby (talk)16:35, 6 December 2021
 
 
 

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/Help test the terminology gadget!/reply (15).

 

It's a great gadget indeed. However, it would be more helpful if a "category" feature is introduced into it.

For example, our current glossary table sort all terminologies by project.

If we can do it with the gadget, hopefully we can eventually replace this page with the terminology gadget's definition page, which can help avoid duplications (there are two glossary tables currently!) and out-of-sync content.

Thank you!

Tranve (talk)06:00, 20 January 2022

@Tranve: Sorry about the (very) late reply here – I thought I had written a reply before, but I guess I forgot (or forgot to save).

Actually a category feature was something I originally envisioned for the gadget, but I quickly came to the conclusion that it would add another level of complexity that would make it more difficult to use for the end-users. Therefore I think it is better to handle such cases by for example using templates (or even just plain text) saying something like "this translation for this term only applies in the <XYZ> context". What do you think?

Jon Harald Søby (talk)13:40, 3 May 2022
 

Hello Jon Harald Søby,

I've seen a problem. I wanted to let you know.

In RTL language Can 't copy the translation of a term that already added.

I have to write the translation again in text area.

It would be very good if it were possible to copy the translation by right-left-click.

Beginneruser (talk)21:46, 3 May 2022
  • right-click
Beginneruser (talk)21:47, 3 May 2022

@Beginneruser: Hmm, where are you trying to copy from? From the pop-up with the translation/usage notes? You should be able to do that by highlihting the translation and press Ctrl+C or right-click+copy, just as with any other text on a web page. There is no special "copy" function in the gadget.

Jon Harald Søby (talk)08:49, 6 May 2022

In RTL language, Can't copy translation from the pop-up by press Ctrl+C or right-click+copy

Beginneruser (talk)17:29, 6 May 2022
 

I mean, when the text is copied, something else is pasted

Beginneruser (talk)17:34, 6 May 2022

@Beginneruser: It works like it should for me. You are highlighting the text first, right? What browser are you using?

Jon Harald Søby (talk)09:46, 8 May 2022
 
 
 
 
 

Request for deletion: Delete grammatically incorrect pages

Hi, I'm a programmer at CeJS. Recently I moved all pages related to "can not" to "cannot". Somehow, although FuzzyBot moved these pages, it created pages related to "can not" again (e.g., Wikimedia:Cejs-can-not-determine-chapter-no-from-title-«$1»/qqq‎) I would like to know if it is possible to remove these wrong "can not" pages? Thank you.

The pages are listed here.

Kanashimi (talk)21:52, 5 May 2022

messages ids are independant of translations. You can use the "cannot" form in Englush even when keeping the message id (using "can-not"). What you want is to rename all pages (in all their translations simultaneously).

Verdy p (talk)10:16, 8 May 2022

However, FuzzyBot has moved the pages once. e.g., Wikimedia:Cejs-cannot-determine-chapter-no-from-title-«$1»/en. So I think these "can-not" pages are redundant pages.

Kanashimi (talk)12:11, 8 May 2022
 
 

Nogai language; Nog-Cyrl and Nog-Latn

Hello, is it possible that we can get nog-cyrl and nog-latn codes for translation in cyrl and latn?

TayfunEt. (talk)16:46, 5 May 2022

As I already replied in another thread, please provide reliable sources that show that the Latin alphabet is standardized and used in formal media, such as professionally published newspapers, books, and websites. Omniglot and Facebook are not reliable sources.

And please don't change the portal to say that the Latin is supported until you provide such reliable sources.

Amir E. Aharoni (talk)09:36, 8 May 2022
 

Cejs still has NO valid licence

The "Corlorless echo JavaScript kit" (Cejs) still does not indicate any valide licence, here on this wiki, but worse neither on GutHub (where it origiantes and where translations are imported).

Please contact "kanamasi" (I don't know which user account he uses on Translatewiki.net, all I see are his imports via "Fuzzybot", made in Japanese and Chinese, in addition with the submitted "source" made in approximate English, that needs fixing, as visibly English is not his primary language), so that he correctly states the licence in his GitHub repository (where translations made on TWN, under CC-BY-3.0 licence) are imported and where that licence should be stated to cover at least these imported translations (as required by TWN terms, and by the CC-BY-3.0 licence).

Then when it is done, he should fill in the project portal with the basic missing info.

See also: https://github.com/kanasimi/CeJS/issues/22 for the bug report I made on his GitHub project.


Also I wonder why this project is imported in the "Wikimedia" namespace as it does not target Wikimedia, and it is not a Mediawiki extension but is a separate framework, and is not supported by Wikimedia (and does not use the same licencing terms).

There's also a risk of polluting the Wikimedia namespace or colliding with it (possibly overwriting previous resources maintained by Wikimedia for unrelated messages), if his translations units are not using a coherent "Cejs-" prefix. As well Wikimeia is ongoing a cleanup process of his own messages and keeping Cejs messages there does not help Wikimedia performing this maintenance.

I suggest renaming/moving all these "Wikimedia:Cejs-*" messages in their own namespace, and block the account currently used by "kanasimi" with FuzzyBot, from writing anything else in the Wikimedia namespace (and instead grant him the right to use its own new separate namespace like "Cejs:", without needing to keep the "Cejs-" prefix).

Verdy p (talk)16:14, 6 May 2022

Thank you for your continued help and contributions. You can contact me through this account.

I have previously released this library under BSD-3-Clause.

I need to know if BSD-3-Clause is compatible with CC-BY-3.0 first. Then I can proceed to the next step.

Kanashimi (talk)11:02, 7 May 2022

In my opinion, this is OK because both licences are open and require the attribution (and an explicit dated statement of the copyright holder, and at least providng a link to the licence (but you may also include the text of the licence into your repository).

In the "LICENSING.txt" (in your GitHub repository), you should also say that translations are *also* licenced with CC-BY-3.0. You can as well include a copy of the BSD 3-clauses, and of the summary text of CC-BY-3.0 (with a link to the web page on the Creative commons site for details).

When this is done, you can complete the portal with the missing licence(s) for translations made here. If you are not sure if they are compatible, just state that translations are licenced under both CC-BY-3.0 and BSD-3-Clause (on this wiki make a link in the project portal to your LICENSING.txt file in your GitHub repository, and fill in the "Contact" info).

Thanks.

Verdy p (talk)12:12, 7 May 2022

I have added the license file and added some notes.

Kanashimi (talk)22:46, 7 May 2022

PERFECT!

Verdy p (talk)08:58, 8 May 2022
 
 
 
 

When using plural expression of gettext in MediaWiki, is there a way to pass the amount parameter to <nowiki>{{PLURAL:GETTEXT|</nowiki>?

Hi. I find it mentioned here that there is no regular specification. But the example currently shown does not mention how to pass in the amount parameter, for example:

{{PLURAL:%1|one|others}}

Is there a way to pass in the amount parameter? Like this?

{{PLURAL:GETTEXT:%1|one|others}}

Kanashimi (talk)11:18, 7 May 2022

What are the limitations of FuzzyBot?

Hello everyone.

I am the programmer of CeJS. Recently FuzzyBot doesn't seem to sync messages with the source code on Github.

I think there might be some errors during execution? I noticed before that the bot doesn't seem to be able to import numeric information. I'm wondering if this time the import is also broken due to some limitation? Maybe we can put the error message somewhere so people know what to do if something goes wrong?

Kanashimi (talk)21:49, 2 May 2022

Since when did you start noticing this? If its just this week, it could be because we've had a delay in processing some of the imports manually. It would then backlog importing the rest of the changes as well.

Regards,

Abijeet Patro (talk)07:20, 5 May 2022

I found this problem about 1 week ago. Since I also changed the i18n json file, I guess those changes caused the problem. Well... Now it seems to be working.

Kanashimi (talk)08:28, 5 May 2022
 
 

How fast do you turn in translations?

How fast do you turn in translations?

StarrySky (talk)02:59, 5 May 2022

There's no single answer. This all depends on each project, i.e. from their maintainers: it's up to them to request the exports from translatewiki.net and then import them into their development repository, test them, patch them if needed, submit corrections back to here to fix some locales or typos, or problems reported by translators; then when this looks OK for them, deploy their development version to a release of their application.

Each project may have information on their project page here in translatewiki.net detailing how often they update their application into their development repository, but the release of apps containing them may still be delayed. So look at thje version of each application (or webapp/website/wiki) you are using, and ask to their local administrators to ask them when they will release them.

Translatewiki.net only wants that translations made here are imported into an accessible development repository so that users can also test their translations in a test environment even if it's still not released (but the application should release in a few months, or ther contact maintainers must reply to support questions and inform translators about what is going on (they should clearly state, when they are requested, that they really continue to develop their app and will support new translations).

Otherwise, without any answer, the translation project hosted here may be stopped by a decision made by TWN admins (and TWN users will be informed); a suspected project may also be resumed if a stalled project has been forked and taken by someone else that wants to support it and update it.

Translations for MediaWiki core messages and for MediaWiki extensions supported by Wikimedia usually take no more than one week to be imported, tested and deployed (but there could also be delays, notably when messages are updated for a newer version of some extension which is still in beta: the deployment will not go live in standard wikis, but only in specific test wikis: you have to look for information in Wikimedia Phabricator to see the deployment plan, or you can read their "Technical newsletter" in MetaWiki for those new messages modified or added in English; however simple translations of messages that were already released in English can be deployed much faster, so remember that there are different stages for deploying them, including within the same project or the same extension, depending on the application or extension version).

Verdy p (talk)03:51, 5 May 2022
 

Inconsistant sort order in categories

See for example, look at end of index letter "A".

It looks like the SQL database uses an inconsistant sort order, or the SQL client used does not properly implement the sorting (very likely an incorrect implementation of the "Quicksort" algorithm, with a missing "=" sign when comparing keys).

This causes the pages navigation (that goes from page to page of 500 members each) to skip a (variable) number of entries, as the starting position (from= value in the GET request) is not honored.

In the category above, just click on letter "A": this shows only the members starting by "A" incorrectly sorted at end of the list (as viewed from the start of the list). Click on the Greek Alpha key: all Greek letters are skipped, you need to go backward and you'll see the missing Greek names, and some Cyrillic names starting by the Cyrillic letter "A". Click on the Hebrew Alef key, you don't see any Hebrew name and you don't even see the first Arabic names normally sorted after it (such as those starting by an Arabic Alef, which will be seen only when going backward to the previous page).

In some cases, going backward in long list will also skip some intermediate values, which will then never be listed.

Note that when generating the HTML, the retrieved 500 first keys (internal SQL: "LIMIT 500" in the query, which should be using a comparator "WHERE key >= 'index') are sorted again in the client (but still inconsistantly) before generating the actual list. Collation also seem to not use the same rules (or locale) in the SQL server and in the webapp (in PHP).

It is also very likely that sorting indexes for categories are incorrectly computed (using incorrectly generated collation keys) and that they were not reindexed when there was an upgrade of the SQL server software.

So categories that have more than 500 members (notably categories of users) are not navigatable, and cannot be seen entirely from the web interface (this does not seem to affect the same way queries using the Mediawiki API, for example returning list of category members in JSON).

The non-regeneration of collation keys for page names (computed normally when performing "INSERT" or "UPDATE" on invididual rows) is causing issues, but I doubt this is caused by the internal implementation in the SQL server, which just internally uses a binary UTF-8 sort, or is supposed to use it; collation keys are stored in a supplementary column, separately of the UTF-8 page name, but taking into account the sort key given in [[Category:categoryname|custom-sort-key]]) as a prefix followed by some separator, which should be a collation element lower than the collation element for an ASCII space, so that separator should be a control character like 0x01; if it is not possible to use that separator due to data restriction on the stored collation-key column, then that separator should be " !", i.e. a SPACE followed by an exclamation mark.

Now this wiki seems to apply it own custom sort after retreiving each subset of 500 rows, to use an ICU based collation on this subset. This custom sort is visibly affected by the incorrect implementation of the QuickSort algorithm, or it is not stable. The result of that is that list of members displayed are incoherent, they are missing items which are not listed (incorrectly dropped during this custom sort).

Can you investigate this? Where is the source code of the client used on this wiki? can you investigate if stored collation keys for list of "sortkey+pagenames" in categories are correctly generated (you may need to use an asdmin script to regenerate these data columns constainong the generated collection key, (i.e. custom sort key + separator + pagename + separator + namespace), then filtered and possibly truncated to avoid exausting a length limit. It is even possible that different rows may have the same collation key stored in the database even if they are for distinct page names.

Verdy p (talk)06:02, 5 May 2022

Request for protection

Hi

I want fix translation of MediaWiki:Wikieditor-toolbar-help-content-file-caption/fa but get the warning:

Note: For security reasons, it may be impossible to translate this message on translatewiki. If you cannot submit a translation, please contact an administrator. See task T294760 in Phabricator.

Admin, Please change translation to متن برنگاشت.

Beginneruser (talk)21:18, 30 April 2022

Oh, I'm sorry

I wrote a bad title for request

Beginneruser (talk)21:20, 30 April 2022
 

Alphabet changing Nogai language

TayfunEt. (talk)09:17, 18 April 2022

Is this Latin alphabet used in any professional publications, such as books or newspapers? Is it taught in schools?

Or is it only used in informal writing?

Amir E. Aharoni (talk)10:15, 18 April 2022

There are some infos on https://en.wikipedia.org/wiki/Nogai_alphabets (3 scripts: Cyrillic, Latin and Arabic, but their usage depend on the country where Nogay speakers are living). For now the existing Nogai translation have been made using Cyrillic by default. Wikipedia claims that Latin is used today, and Cyrillic introduced in 1962 may not be used everywhere, or could have fallen out of use after political changes in the region where Cyrillic was introduced and may be enforced for a bit less than 30 years).

Verdy p (talk)15:55, 18 April 2022
 

Here are some sources: The Latin alphabet used today: https://www.omniglot.com/writing/nogai.htm

Used to translate: https://lyricstranslate.com/tr/ka%C3%B1ili-kanl%C4%B1.html

TayfunEt. (talk)09:30, 24 April 2022
 

And is it possible that the untranslated words will show in Kazakh (Kazakh language is very similar to the Nogai language)?

TayfunEt. (talk)09:35, 24 April 2022

Fallbacks should use the same script. So Nogai-Cyrillic could fallback first to Kazakh-Cyrillic, Nogai-Arabic could fallback first to Kazakh-Arabic, Nogai-Latin could fallback to Kazakh-Latin. For now only the Cyrillic version of Nogai is enabled (as the default script), meaning that it can only fallback to Kazah-Cyrillic.

Mixing Cyrillic and Latin because of partial translations is often possible without much problem in, composite messages (contain plaeholder varaibles for values that are also translatable with fallbacks).

However mixing Cyrillic+Arabic scripts or Latin+Arabic scripts often causes layout problems (but the same can be said when the default fallback is to English, written in Latin, and Kazakh or Nogai would be written in Arabic).

Such request is enviable but Kazakh needs also efforts to get more properly translated, notably in the Arabic script, before that later variant becomes a viable fallback for Nogai-Arabic (which is still not enabled for now anyway, so this requests should not cause major problems: we'll talk in another time about the opportunity to start translating to Nogai-Arabic, unless another possible fallback to Persian/Farsi is prefered in that case, because Persian is much more advanced and much mlore used today than Kazakh-Arabic which is historical).

Verdy p (talk)16:41, 24 April 2022

We will to use now the latin script as a default script and this means that the fallback language (Kazakh) needs to be in latin. For the scrips, what I think is something like the Crimean Tatar Wikipedia there is also used two scripts and the main script is latin.

TayfunEt. (talk)18:46, 24 April 2022
Edited by 2 users.
Last edit: 12:27, 25 April 2022

So you request that existing translations made in Cyrillic be moved to a subscript extension?

And make Latin-script the default (without needing an extension, replacing the existing Cyrillic version already moved before that), or just create an additional Latin-script extension (like for Kazakh, which is more likely to occur, giving a sotuation similar to Serbian, Chinese or Kazakh without any predefined default choice)?

Question: Is it viable to define a stable transliterator between Cyrillic and Latin for Nogai (such as the one used in Serbian) with an agreed standard allowing such conversion to be bijective (i.e. reversible without loss and without creating orthographic problems, except by using a dictionnary of known exceptions, like the large one used for Chinese between its two standard script forms)?

Verdy p (talk)20:31, 24 April 2022
 
 
 
 

TayfunEt., discussing it all is pointless until you bring up a reliable source that this Latin alphabet is used anywhere formally for school teaching, books, newspapers, professional websites (not social network posts), or something comparable. Omniglot is not a reliable source—it's just one guy who adds puts anything that people send to him on his website.

To the best of my knowledge, the only formal alphabet for Nogai is Cyrillic. Until proven otherwise, it will remain the default here.

Amir E. Aharoni (talk)09:40, 28 April 2022

And there are many proofs of the use of Nogai in Romania (Northern Nogai) and Turkey (Southern Nogai), written with the Latin script. The use of Cyrillic is only for Nogay people that emigrated further to the North at the beginning of the 20th century with the transfer of most of the former larger Nogai region to Russia and rapidly in USSR into the Moldavian SSR and in the Ukrainian SSR (including in Crimea, now in independant Ukraine but occupied by Russia).

Yes there are linguistic links with Crimean Tatar, but Tatars in South-East Romania are well known, most of them however moved to Turkey, and in both countries, they use the Latin script today. Nogai is not just for Russia or Ukraine, where they were assimilated/confused with Crimean Tatars that use the Cyrillic script for their language. Linguistically Nogai is recognized in Romania and is spoken/written by "Romanian Tatars" (some of them assimilated to "Turkish" people), but they don't use the Crimean Tatar language or its Cyrillic script. Nogai people in Romania an Moldova now share many more familial links with Nogai people in Turkey and have more relations with them than with Crimea (Ukraine or Russia), even if Nogai people in Romania are also now in contact with Bulgars (that use the Cyrillic script even in Romania) and also with Greeks, but in a limited way due to religion (Nogais are mostly sunnite muslems like Turks, whereas Romanians, Greeks, and Bulgars are mostly catholic or orthodox christians).

Nogai political parties in Southeastern Romania (generally islamic and often designating themselves as "Tatars" rather than "Turks" because they promote a local autonomy and better acceptance of their islamic religion) use the Latin script for their local communication and they are also finding financial and media support from Turkey due to their active and strong links. And if they don't communicate with Nogai language, they communicate in Turkish, even if officially they also have to communicate in Romanian for local elections. The links with Tatars of Crimea are almost cut since a bit more than one century but not the links with Turkey when it was founded at end of WW1 after the Ottoman Empire collapse (which caused the historic Nogai region to be splitted essentially in two parts between the Romania and the successors of the Russian Empire).

Verdy p (talk)10:15, 28 April 2022

There is a project supported by Tubitak in one of the prominent university of Turkey. They are using Turkish-based Latin script.(http://turkiyenogaylari.hacettepe.edu.tr/) Many papers in dergipark also uses latin script. (ie. TDD Journal)

Joseph (talk)14:50, 30 April 2022

These two links don't directly show texts in the Latin script or documentation of orthography. Can you please give direct links to such texts? I tried searching for it in the websites, and couldn't find anything.

Note that transcriptions of words or sentences in scientific papers are not really texts, because that's not what usual people use for reading and writing.

Amir E. Aharoni (talk)08:43, 1 May 2022

Just look at the video on this page, whose title is clear (even if you don't read Turkish, you can easily decipher it). Go to the description given in Youtube. You'll see that this is an active universitary work, made in Turkey, and sustained by Unesco (so this is serious).

Verdy p (talk)16:23, 2 May 2022
 
 
 
 
 

Request for protection

Hi

I translated a well-known message same other messages, but Danialbehzadi user revert my edit.

Please revert the message to revision and protected the message page.

Beginneruser (talk)13:04, 30 April 2022

What is the problem? The English message uses arrow heads only, not plain arrows. The words "Previous" or "Next" are not changed and have kept the translation, but were changed to show only arrow heads (actually it is a single chevron, but it could as well be a filled triangle, pointing to the left or right (with direction changed betweeen RTL and RTL scripts).

The single chevron (punctuation sign) may eventually be changed if it looks too similar to a native letter of the script, and the long arrows are not necessarily the best fit for buttons, where a more common symbols used for example in media players for skipping to the previous or next title/chapter is usuaally a single triangle).

Some other messages in English use a double chevron, which may be confused with the standard quotation marks. In all cases, this is a symbolic use here, meant to be visual but having a string relation with a "forward/backward" direction (tied to the script direction and not necessarily "left" or "right", so it has to be mirrored correctly), and it does not have the value of a punctuation (using full arrows is genrally associated to a binary relation with two elements represented, but that's not the case here).

Ideally, I would have used filled triangles (◂▸) even in English rather than single chevrons (that are not enough visible and may be misinterpreted).

So your argument of being a "well-known" message is a bit strange.

Verdy p (talk)13:28, 30 April 2022

Hi again

I did convert → to ‹

My problems is not (◂▸) signs, The problem is meaning of "Previous" term.

Traslation that Danialbehzadi user used for this term is not uncommon.

In all message used same my translation but Danialbehzadi user only just edit the message by a mean not used at all.

Please revert to revision and protected the message page, because this user again revert my translation in message.

Beginneruser (talk)15:39, 30 April 2022
 
 

Username change

Hi, can I request a username change to (أَحمد), please? Thank you.

FiberAhmed (talk)19:29, 27 April 2022

Internal error

Edited by 2 users.
Last edit: 02:50, 27 April 2022

I have just had the following internal error when trying to save one translation. Maybe you should check it.

This message is logged, but you might want to report it on #mediawiki-i18n @ freenode or to user nike in this wiki.The command 'perl -MYAML::Syck=LoadFile -MPHP::Serialization=serialize -wle 'my $tf = q[/tmp/yaml-load-ksTiXB];my $yaml = LoadFile($tf);open my $fh, ">", "$tf.serialized" or die qq[Can not open "$tf.serialized"];print $fh serialize($yaml);close($fh);' 2>&1' died in execution with exit code '2': Can't locate YAML/Syck.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.0 /usr/local/share/perl/5.10.0 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .). BEGIN failed--compilation aborted.

Backtrace:

#0 /www/w/extensions/Translate/utils/TranslateYaml.php(52): wfDebugDieBacktrace('The command 'pe...')
#1 /www/w/extensions/Translate/utils/TranslateYaml.php(11): TranslateYaml::syckLoad('---?BASIC:? id...')
#2 /www/w/extensions/Translate/utils/TranslateYaml.php(19): TranslateYaml::loadString('---?BASIC:? id...')
#3 /www/w/extensions/Translate/MessageGroups.php(763): TranslateYaml::load('/www/w/extensio...')
#4 /www/w/extensions/Translate/MessageGroups.php(779): MessageGroups::init()
#5 /www/w/extensions/Translate/TranslateEditAddons.php(184): MessageGroups::getGroup('')
#6 /www/w/extensions/Translate/TranslateEditAddons.php(170): TranslateEditAddons::getMessageGroup(1222, 'User_block.revo...')
#7 /www/w/extensions/Translate/TranslateEditAddons.php(25): TranslateEditAddons::getKeyCodeGroup(Object(Title))
#8 [internal function]: TranslateEditAddons::addNavigation(Object(OutputPage), '<p>Este bloqueo...')
#9 /www/w/includes/Hooks.php(133): call_user_func_array(Array, Array)
#10 /www/w/includes/OutputPage.php(1124): wfRunHooks('OutputPageBefor...', Array)
#11 /www/w/includes/Article.php(855): OutputPage->addParserOutput(Object(ParserOutput))
#12 /www/w/includes/Wiki.php(499): Article->view()
#13 /www/w/includes/Wiki.php(73): MediaWiki->performAction(Object(OutputPage), Object(Article), Object(Title), Object(User), Object(WebRequest))
#14 /www/w/index.php(116): MediaWiki->performRequestForTitle(Object(Title), Object(Article), Object(OutputPage), Object(User), Object(WebRequest))
#15 {main}
  • Note: I was trying to translate this message: User blocks.revoke.past ("This block ended %{time} and cannot be revoked now.").
Toliño Fala aquí comigo 18:40, 19 May 2010

Niklas made a little judgement error and experimented with a different YAML parser... OUCH.

Siebrand23:34, 19 May 2010
 
First page
First page
Previous page
Previous page
Last page
Last page