Jump to content

Support/LiquidThreads

From translatewiki.net
This page contains archived discussions using the Liquid Threads extension. You can still participate in existing conversations, but you should start new conversations using the new discussion tools on the main talk page.

Contents

Thread titleRepliesLast modified
Remove 'sh' (Serbo-Croatian) language ?1006:08, 17 October 2023
Username change211:56, 10 October 2023
Request for variants under Wuu116:37, 16 July 2023
Unused message clean up request108:50, 14 July 2023
Translation administrator, administrator, bureaucrat612:32, 14 March 2023
Username change113:35, 24 February 2023
Wikimedia:Wikiauthbot-*/sr should be moved to Wikimedia:Wikiauthbot-*/sr-ec123:10, 14 February 2023
Replacing the discussion system1515:02, 14 February 2023
Enable translation tools for Acehnese Arabic script515:24, 11 February 2023
Please archive my talk page to allow me to use DiscussionTools409:14, 8 February 2023
Cannot translate108:03, 8 February 2023
Request for temporary administrator right306:57, 8 February 2023
"You can translate it in minutes!"405:22, 5 February 2023
Request for the enabling of Hassaniya in TranslateWiki.209:57, 30 January 2023
MediaWiki:Tutorial-popup-text2/en221:55, 28 January 2023
Request for the enabling of Hassaniya in TranslateWiki. (2)001:48, 28 January 2023
Translations that don't use plurals are marked outdated218:35, 26 January 2023
Remotetasks218:51, 25 January 2023
Request to enable: Hindko418:37, 25 January 2023
ماهي المواضيع 014:37, 25 January 2023
First pagePrevious pageNext pageLast page

Remove 'sh' (Serbo-Croatian) language ?

This is a follow-up on an IRC discussion I've had with Nike about a year ago; I'm posting it here, since I got no feedback on IRC despite several pings.

TranslateWiki.net maintains a MantisBT translation file strings_sh.txt (was added back in 2019). There are several issues with that:

  • The file name does not follow our naming convention (should be strings_serbo_croatian.txt)
  • Language code sh is deprecated according to https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes
  • The language is not defined in MantisBT configuration ($g_language_choices_arr, $g_language_auto_map)

Reference: original MantisBT issue including IRC chat transcript

-- Damien‎11:29, 14 June 2022

bump...

-- Damien‎17:05, 11 July 2022

sh works. sc is alternative. Sardinian cannot be sc.

Obsuser (talk)‎14:45, 16 October 2022

You are wrong, "sc" is standard for Sardinian in ISO 639-1, BCP47 and Wikimedia wikis and MediaWiki translations (do not assume it being usable for Serbo-Croatian).

"sh" has been removed from ISO 639-1 only (but not "hbs" from ISO 639-3 !), and not from BCP47 (where "hbs" was mapped to be the same as "sh") which more or less still considers it as an alias of "sh-latn" (with the implied Latin script by default). but it has been kept in ISO 639-3 as a macrolanguage (containing "hr", "cnr" aliased by default to "cnr-Latn", and "bs" aliased by default to "bs-Latn"). It is special compared to other macrolanguages because of its implied default script, but "sh-cyrl" is also valid (and comprises "bs-Cyrl", "cnr-Cyrl", and "sr" aliased to "sr-Cyrl").

The old decision taken in ISO 639-1 only is very unfortunate, given than "hbs" has been kept in ISO 639-2 and ISO 639-3 (including in its later revision where it was assigned the "scope" of a "macrolanguage"). That code may be retired in ISO 639-1 not for techincal or translation purpose, but probavbly motivated only for bibliographic use (but many public libraries in the world have not remvoed that classification for their book archives, and notably not for books published in the former Yugoslavia!). But that decision was motivated before ISO 639-3 was released to define the concept of "macrolanguages", and also before the revision of BCP47 (at that time ISO 639-1 and ISO 639-2 were a mess, they were unstable, and most applications chose to ignore ISO 639 and have developed their standards to reference BCP47, and its related IANA databases for language tags, rather than ISO 639; ISO 639-3 has attempted to make a more comprehensive codification, had to fix some codes by definining their scope; BCP 47 was revized to include "grandfathered" tags, and ensure stability and backward compatiblity; today nobody wants to make any normative reference to ISO 63, except for bibliographic purposes with simplified classifications, but not usable at all for translations and technical applications; this is the case of all IETF, W3C, ITU standards, as well as other ISO/CIE/ECMA standards, and many national standard bodies, even if sometimes they took the decision to preserve their own legacy codes and made specific requests to ISO and the IETF to maintain the stability).

ISO 639-1 still has very bad codes like "bh" (which is not even a macrolanguage but a family, not mapped to ISO 639-2 or -3 but to ISO 639-5 as "bih"; note that ISO 639-5 is still very incomplete for classificying language families). As well Wikimedia still has its own legacy codes that violate BCP 47 (but they are slowly being retired and replaced). Wikimedia privately uses "bh" in its wiki domaine names by assuming it refers only to "bho" (Bhojpuri), one of the languages of that family, but it uses other conforming ISO 639-3 codes for the other languages of that family, so that is not blocking any project.

"sh" (Serbo-Croatian) is still valid in BCP47 and many linguists (as well as many native speakers) also consider it as being a single macrolanguage comprising "hr" (Cratian), "bs" (Bosnian), "cnr" (Montenegrin), and "sr" (Serbian), independantly of the "Latn" or "Cyrl" script which they may use, even if languages were separated (even though they are basicalty dialects/variants of each other with excellent mutual understanding, and just some prefered forms in each of them, and minor orthographic differences between locations; but the orthographies in the two scripts are mutually interchangeable, that's why Wikimedia wikis provide an automated translitator for reading/writing them in either script, just as a matter of user preferences). Very few words are in fact localized specifically between these 4 languages and none between the two scripts.

(Note that Wikimedia still uses some incorrect "sr-ec" and "sr-el" legacy codes instead of the standard "sr-Cyrl", "sr-Latn" codes. This is only for its domain names and interwikis, not for HTML language tagging which uses standard BCP47 codes; there also remains some properties in Wikidata still using these legacy codes, but they are deprecated and should be also replaced by BCP47 codes; but this does not apply to sitelinks whose usage in domain names (for wikis) and in interwiki prefixes does NOT violate the HTML standard; Wikimedia still has to cleanup its local use of "nrm" instead of "nrf" for Norman, which severely conflicts with ISO 639-3 and BCP47, as it blocks any attempt to translate to "Narom", a completely unrelated South-East Asian language.)

The best working standard for encoding languages used in translations is BCP47 (i.e. RFC 4646 for its last release and its related IANA database). Let's forget ISO 639-1/2 completely (it will remain in the limbos of some public libraries with their old classification system, but many have converted their catalogs to use BCP47 instead for language identification, plus eventually ISO 639-5 for a very weak classification of language families in book collections; if they need more precide classifications today, they can use BCP47 "private-use" codes, they can also use ISO 15924, including script variants for written documents and artworks, even if these variants are unified in Unicode) !

Finaly note that for translations, we don't care at all about ISO 639 (and its many past defiencies), only about BCP 47 (where ISO 639 is only a partial and unstable source); this is not just for this wiki, or Mediawiki or Wikimedia, this is a standard used everywhere on the web (part of HTML for example, as well as almost all i18n libraries and programming languages using them). Many things have disappeared or changed unilaterally in ISO 639, or have been rejected for use in BCP 47, which is a much more usable standard, more precise, and where stability for language identification was part of the design and kept for ever as much as possible (even if some BCP 47 tags or subtags may become insufficient and may need to be requalified in newer documents, but any translation made with a valid BCP 47 tag will remain valid in any later update; except if thre was a severe error and the tags are exceptionnally marked as "discouraged" in the IANA database, where it may or may not suggest some prefered replacement, if one is most likely for most common usage cases). ISO 639 has only been defined for broad use by libarians for the classification and searches in their catalogs, or for managing copyrights in large categories according to their current practices for data exchanges ; later ISO 639 was partly updated to add "technical use" (motivated by trying to get a compatiblity with BCP 47 (but only on old version, and it was never updated later). ISO 639 broke that technical compatiblity later multiple times. BCP 47 data sources for adding entries in the IANA database have ben publicly documented in multiple RFCs with rationales (that's not the case for ISO 639 whose decisions are closed and limited by copyright issues, with no details about they were vetted, so ISO 639 is not a "best practice", only something endorsed by a few national ISO vetters for their use in their national catalogs who actually dont care at all about using precise and distinctive terminology). Don't refer to ISO 639, it's not a normative reference, just an informal informative reference! Note also that various countries have stopped supporting ISO 639 (which they never approved themselves in ISO TC) in their public catalogs and media libraries, they have adopted BCP 47 instead, the same is true for many publishers, media creators and vendors.

Verdy p (talk)‎15:15, 16 October 2022
 
 

Nike (or anyone else), could you please either

  • delete the sh language, or if it can't be removed, then
  • rename the MantisBT language file to strings_serbo_croatian.txt

So I can (finally) close this issue ? It's been pending for nearly 2 years since we initially spoke...

Thanks in advance !

-- Damien‎17:59, 28 February 2023

sh has been removed from supported languages of MantisBT.

Nike (talk)‎07:54, 15 March 2023

And the "sh" language should not be deleted (it is still valid in BCP47 even if it has been retired ONLY from ISO 639-1) but ideally moved to "hbs" (still valid in ISO 639-2 and ISO 639-3, also valid in BCP47). Wikimedia wiksi however don't need to be renamed (in BCP 47, both "hr" and "hbs" are equivalent).

Other non Wikimedia projects may opt to not support that language, but it has to remain for Wikimedia, until Wikimedia choose to deprecate it as a selectable user language (in the ULS), even if the "sh.*" wikis are kept (and the "sh:" interwiki code also remains valid to point to these wikis, just like possibly the "hbs:" interwiki prefix which should be the new standard/canonical form).

For translations of labels in Wikidata item, "sh" should probably be deprecated in favor of "hbs", though both codes (in both scripts) may only remain used as a common fallback, when individual codes for Serbian (both Latin and Cyrillic scripts), Bosnian (both scripts), Croatian, Montegrin are not used.

As well their legacy variants subtags (with "-ec" and "-el" instead of "-cyrl" and "-latn") should remain only for Wikimedia wikis doman names and interwikis. All other projects (as well as support for lang="*" attributes in HTML, or xml:lang="*" pseudo-attributes in XML or SVG, or "lang(*)" selectors in CSS) should always use the standard subtags from ISO 15924. And in my opinion, even on this wiki, all translations should be done here using the standard subtags. Wikimedia wiki domain names and interwikis however should support the aliases using standard tags.

Those legacy codes cause problems and cause unnecessary complex maintenance: everything should work everywhere using only standard BCP47 codes.

Aliased codes are not exceptional and not a problem: Wikimedia has aliases for example between the legacy "zh-clasical" code and "lzh", or betwen "zh-yue" and "yue". (it's just a long time to define which alias will be the standard/canonical form): these aliases can persist for long and the migration to standard BCP47 can be planned over long periods and implemented step by step, making sure that nothing is broken long after the transition (it may be up to a decennial, there's no emergency to drop these.

The same cannot be said about serious conformance issues like "nrm" that should be fixed in priority, properly announced, involving the community to allow them to make the work needed in many spreaded pages): the first step is then to create all needed aliases from "nrm" to "nrf", and migrate the internal database names. Then the community can work on converting wiki pages, Wikidata items. Here we can then rename all "nrm" resources to use "nrf" instead. Then we need a transition period not lasting more than 1 year (time sufficient to perform full scans an existing data and plan all corrections needed, in pages, templates, Lua modules, external Wikimedia tools and bots) before we drop the aliases on "nrm", keeping only "nrf": the use of "nrm" should be monitored with tracking logs as much as possible for that period, until these logs become almost empty (logs should try to identify the internal or external source of these legacy usages; trackign external sources can be only managed by Wikimedia admins if this requires parsing server access logs, but Wikimedia admins can run a parser that will analayse and detected when can be publicly reported: the community can then work on these external sources, if they are accessible or can be contacted). The one year delay should allow most external seach engines to fix their indexes, notably for the domain names used in URLs.

After that period, "nrm" is closed, deleted, a new wiki is created for Narom which can be requested. Once such Narom wiki is created, the initial homepage should contain a notice saying that it ois no longer about Norman that can be found elsewhere. Some similar banners may also added in Categories or some new "conflicting" pages created in Narom (such creations of pages in Narom will likely be very slow, and conflicts of page names will not occur in many pages as the Norman and Narom languages are very different, but will occur for example if both languages use the same proper names or borrow the same English terms. There will be no surprise for rare users that may have followed links from old pages or other old sites or documents. Those banners may then be removed after about 3 years (but there will be some community information pages about the wiki were we can trace its history and indicate what was migrated and where. Such public history is important to keep for extremely long periods, just like ISO itself also maintains a public history).

Verdy p (talk)‎11:38, 15 March 2023
 
sh has been removed from supported languages of MantisBT.

Thanks for this !

I noticed today that the strings_sh.txt file is still present in the repository, meaning whatever was done is apparently not cascading as part of the translation updates.

Can I simply and safely remove the file in the repository ?

-- Damien‎08:42, 29 August 2023
Can I simply and safely remove the file in the repository ?

Ping...

-- Damien‎14:19, 15 October 2023

Sorry, I missed the notification for this. Yes you can safely remove it.

Nike (talk)‎11:21, 16 October 2023
Show 1 reply
 
 
 
 
 

Username change

Edited by 2 users.
Last edit: 11:56, 10 October 2023

Dear admins,

Is there one of you available and willing to change my current userName KlaasZ4usV to my real name I use on all WMF-projects except this one: Klaas van Buiten and leave a redirect behind. Thanks in advance for support
 Klaas `Z4␟` V: ‎23:16, 5 February 2020

Done!

Abijeet Patro (talk)‎06:43, 8 February 2020

Thank you, grazie, dank u

 Klaas `Z4␟` V: ‎10:09, 20 January 2021
 
 

Request for variants under Wuu

Wuu has two writing systems. At this time, most of the messages are written in simplified Chinese characters, I wish to enable two new variants: wuu-hans "吴语（简体）" and wuu-hant "吳語（繁體）", and fallback to wuu when they are unavailable.

Subarupan (talk)‎08:01, 27 May 2021
 

Unused message clean up request

Edited by another user.
Last edit: 06:31, 10 December 2021

https://phabricator.wikimedia.org/T286291

These zh-tw messages are merged to zh-hant and no longer used.


Winston Sung (talk)‎04:48, 17 November 2021
Raymond‎07:05, 10 December 2021
 

Translation administrator, administrator, bureaucrat

Hi, I have now submitted quite a few translations, and ask if I could be a translation administrator, maybe my efforts are enough too for administrator or even bureaucrat permissions

Justman10000 (talk)‎12:02, 24 January 2023

Why do you need it? Are you involved with user support, vandalism cleanup, or deleting unnecessary pages?

Amir E. Aharoni (talk)‎09:33, 25 January 2023

I ask for translation administrator, not administrator!

Justman10000 (talk)‎23:07, 1 February 2023
 

I would like to oppose this. This person does have an unnecessary hostile communication style, as you can see here and on my talk page.

TMg (talk)‎08:24, 2 February 2023

The TranslationAdmin right does not give additional rights for translating any page or message. It's only for marking new wiki pages to be translated by the translate UI, or to manage incoming projects to be translated in the Translate UI.

Translation admins should just check that the formatting used is minimized, so that translators won't be worried about syntaxic tricks or the presesentations. They should also be aware of requirements for RTL versus LTR languages and of the requirements for many languages (notably not assume an English punctuation, including for whitespaces). They should prepare pages with minimized translation units, should avoid placing long list of items into the same translation unit (especially when the list is evolutive, so that new, modified or deleted items can be easily manages without having to review the whole list again). They should avoid creating "patchwork" messages (translations should keep sentences unbroken, using translation variables if needed for embedded fragments).

TranslationAdmins should also test their pages submitted for translation, by making a full translation to at least one language and experiment what other translators will see and will have to work with for all other languages. But for that work, these translations will still require review by peer translators: a TranslationAdmin has no specific privilege to force a translation against other translators.

As well TranslationAdmins should not arbitrarily alter constantly the format of the source page to be translated, and should be doing the "dirty work" of adapting technical/syntaxic changes themselves in all languages for which there are existing translations, to minimize the work to be done again by other translators (that's why it's important to perform a full translation to at least one language, using translate UI like every other translators will do). This means that a translator admin MUST be at minima bilignual (knowing English correctly but also another language natively and be trained to what other non-Latin scripts need, notably Arabic, Hebrew, Chinese or Japanese, Thai, and be ware about very different punctuations MUST be used in Spanish, Greek, Armenian, Arabic, Chinese or Arabic, and different capitalization rules even in the Latin script).

Even for developers of projects to be translated here, they may not be good translation admins if they just know English and are unable to work with contents in other languages. They should work with people that are enough trained with internationalisation issues and not consider that requirements for other languages are "not needed" jsut because they feel this would be too complex for them to maintain (this is difficult only because they don't understand the issues or did train themselves): if this is the case they should work in cooperation with other translation admins that can be assisting proxies between developers and translators to explain and find a solution that will help each other.

Verdy p (talk)‎12:03, 2 February 2023

I know what a translation administrator does.... Otherwise I would not apply... But yes, here it already seems to run differently than in other projects

Justman10000 (talk)‎12:32, 14 March 2023
 

I was just pointing something out to you?

Justman10000 (talk)‎12:29, 14 March 2023
 
 

Username change

I would like to change my username to Zenfiric

Милан Јелисавчић (talk)‎13:11, 24 February 2023
 

Wikimedia:Wikiauthbot-*/sr should be moved to Wikimedia:Wikiauthbot-*/sr-ec

Subject says it. The */sr messages are not editable, telling users to edit */sr-ec instead. I'm not being allowed to rename them either.

I don't know if there is any other project still using */sr; the search features don't seem to make it easy to find out.

McDutchie (talk)‎13:41, 31 January 2023

Actually "/sr-ec" is an old legacy bogus code used ONLY on some Wikimedia sites, it should be "/sr-cyrl". Many things even in Wikimedia wikis are using "sr-cyrl" instead, as much as possible, but the conversion is not terminated. Then ""/sr" is still correct because it is the default script used most of the time. The creation of Serbian in the 1990's was a nightmare to manage (including the management of numerous ISO codes for country divisions used as legacy language variants in BCP47), whereas the deletion of "/sh" in ISO 639 (but not BCP47) was a severe error. Unfortunately at that time, ISO 639 was a complete mess, ISO 15924 did not even exist at that time, as well as ISO 639-3 with the concept of macrolanguages, and we were operating with an antique version of BCP 47.

Since RFC 4646 and ISO 639-3 all is clear, but "sr-ec" and "sr-el" (complete inventions by some uninformed Wikimedia users that did not care about existing standards at that time that stated that "EC" at that place would indicate the Ecuador country; same remark about "EL" which was exceptionnaly reserved in ISO 3166-1 for use in the European Union documentation for referencing Greece instead of using "GR") should no longer be used at all and should have been fully migrated by Wikimedia to use standards since many years (but apparently no one cared because there was no demand to use "sr-ec" and "sr-el" according to standard (Serbian having no demonstrated usage in Ecuador, it may be used in Greece but with no specific regional variant found in European Union documents using the "EL" code for that, so there was never any emergency to change that... except adding unnecessary complications in i18n support libraries and databases and invalidating some security tools or indexing tools that want full BCP47 conformance).

Verdy p (talk)‎15:07, 31 January 2023
 

Replacing the discussion system

As you know, translatewiki.net is using LiquidThreads for discussions. It is an extension that hasn't been developed in about 10 years, is barely maintained and broken to some extend. This has been known for years, and I have been thinking of replacements.

Now it seems StructuredDiscussions (née Flow) is going to face the same fate: no longer actively developed nor maintained.

There is a new system in the works, called DiscussionTools, which builds on top of the existing talk pages. Who knows, maybe DiscussionTools will face the same fate in the future, but that should not be a such a big deal, since the existing talk pages keep working, which cannot be said for LiquidThreads or StructuredDiscussions, if those extensions are removed.

What do you think about enabling DiscussionTools on this wiki with the eventual goal of archiving the current LiquidThreads discussions as read-only? There are probably hundreds of pages using LiquidThreads, so some bot activity may be needed to archive them.

I think feature-wise we would not lose anything important if we switch over. With discussion tools we would gain visual editor support.

Links:

Nike (talk)‎11:46, 12 January 2023

Yes! Excellent idea.

I liked Flow, especially for its excellent mobile support. Unfortunately, it's probably doomed, so there's no point in discussing it.

The DiscussionTools extension offers a good balance of the classic talk pages with some new features that one would expect on a modern website.

Amir E. Aharoni (talk)‎19:49, 12 January 2023
 

I would be very happy for us to switch to DiscussionTools – I have used it since it first became available in beta on Wikimedia projects, and the experience has been both pleasant and intuitive. It's seamless integration with "ordinary-style" talk pages is also a major plus. So yeah, I'd be very happy if we switched.

Jon Harald Søby (talk)‎17:11, 17 January 2023
 

Feature-wise, is it possible to link to a particular reply in a thread with DiscussionTools? I realize it might not be the most important feature, but I remember using it a few times here, and it was handy. (It's nice not having to dig history to find a diff corresponding to a reply).

whym‎08:53, 31 January 2023

Not currently, but it's a planned feature: https://phabricator.wikimedia.org/T275729

Nike (talk)‎09:20, 31 January 2023

To be exact: it is possible, but there is no UI yet to get the correct ID. If you happen to know the ID (e.g. using the user script described in https://www.mediawiki.org/wiki/Topic:Wmredg44lh8v9x9i, or using the browser developer tools), you can already link to it.

Tacsipacsi (talk)‎10:49, 14 February 2023
 
 

I agree with such a switch. Some temporary pain would be worth it.

McDutchie (talk)‎13:32, 31 January 2023
 

DiscussionTools has been enabled. It depends on VisualEditor, so that too is now available.

The process to start using discussion threads is a bit complicated.

For pages with no existing threads:

  • Create page or edit page to add {{#useliquidthreads:0}}

For pages with existing threads:

  • Move the page from X to X/LiquidThreads (better not to leave redirect, as it makes the next step easier)
  • Edit page X/LiquidThreads to add {{ArchivedLiquidThreads}} (see below)
  • Edit page X to add {{HadLiquidThreads}}

LiquidThreads is still showing for all new talk pages. There is an option to disable that, but it will hide existing threads unless {{#useliquidthreads:1}} is present. Only if we add the manual opt in to all such pages, then can we turn of LiquidThreads by default in the future. This is done automatically with {{ArchivedLiquidThreads}}.

I made one example to test so far: Translating talk:Index.

Nike (talk)‎08:49, 7 February 2023

Thanks for doing this!

A question about the last step: I managed to add {{HadLiquidThreads}} to my user talk page by putting action=edit in the URL, but I couldn't find any other "Edit" button. Have I missed it, or is there really no other way?

Amir E. Aharoni (talk)‎12:54, 7 February 2023

There is small [Edit↑] which is hard to see. Also it does something funny with redirects, so I had add action=edit as well.

Nike (talk)‎13:48, 7 February 2023

If the page doesn't exist, it's instead red [Add header].

Nike (talk)‎13:50, 7 February 2023
 
 

Your instructions do not work. Users cannot *move* their talk page (that action is disabled/hidden, even when moving to a subpage of their talk page). Only you can do that. Do you want all users to ask you to make these moves?

Verdy p (talk)‎11:10, 14 February 2023

A patch that enables everyone to move pages is under review.

Tacsipacsi (talk)‎13:09, 14 February 2023
 
 

Support DiscussionTools. We should probably investigate how to make new talk pages not use LQT by default. Bonus points for converting existing LQT discussions into normal threads so the extension can be removed eventually (since it's unmaintained, etc.) without breaking existing content.

—MarcoAurelio (talk)‎14:38, 14 February 2023

New talk pages (i.e. page not existing yet) already have LQT disabled.

Nike (talk)‎14:50, 14 February 2023
 

I agree that the many pages created LQthread should be convertible to normal MediaWiki subpages (merging their titles and regenerating default signatures and dates).

However note that there's a problem in how many subpages we'll need and how to preserve the threading: we can't merge all them into a single subpage without exhausting some limits, or breakign the threads; additionally, if we merge separate threaded messags into the same subpage, there's the need to preserve the indentation, and their relative order. Some existing threads have many levels of replies, so in a first step each message should be a separate subpage, then a default parent page could transclude them (within indented blocks). Note that in LQthreads, replies may have different titles than the message they were replying to in the same thread, so the titles of each thread cannot be a normal Mediawiki section header, EXCEPT the top-level where it could be used as a section header in the wiki subpage (with == for normal second level) (for all other levels, it would become a === for a unique third level, the indentation in the parent page transcluding them could insert the indentation needed, using for example an collapsible box template: the header of the collapsible box would be the signature and date).

Even a single LQ message in a talk page would be come at least 2 subpages: a parent subpage for the presentation and containment, containing a collapsible box template.

Such conversion tool would not just be for this wiki but for any Wikimedia wiki where LQ is about to be deprecated, before it is finally uninstalled. Idelaly it would require the use of some external bot trying to make the conversion, it would need parameters to set the source LQ talk page (where LQ thread were attached), and the target pagename (not necessarily the same, and possible with an editable subpage name instead of some default "/old Liquidthread messages", as user pages have various ways to organize their archives.

Once the user owning the user talk page (or the community otherwise that manages a content talk page) approves the conversion, the old threads could be deleted (but there's an issue to preserve the history for copyright reasons, so most probably they would be frozen: all futher edits or additions would be in the standard mediawiki (sub)pages).

Finally the conversion bot should be made part of DiscussionTools, which would also have ways to manage/reorganize archives.

Verdy p (talk)‎14:52, 14 February 2023
 
 

Enable translation tools for Acehnese Arabic script

Hi, could you please enable translation tools for Acehnese Arabic script (Jawoe script) ?

Si Gam Acèh (talk)‎17:34, 7 February 2023

For which purpose?

Is it used anywhere else online?

Amir E. Aharoni (talk)‎12:24, 9 February 2023

We will create Acehnese Wikipedia in 2 scripts, Latin and Jawoe/Jawi (Arabic script).

Si Gam Acèh (talk)‎17:02, 10 February 2023

OK, but that's not what I asked. Where else is it used online?

Amir E. Aharoni (talk)‎06:04, 11 February 2023

The Jawi orthography (based on the arabic scrip) is very common in Indonesia (especially for islamic culture, Just remember that Indonesia is the country with the largest islamic population, and it is official in one of its state with islamic law, except in Bali where it is second after buddhism, and in Western Papua where it coexists with Christianity).

Lot of Indonesian sites display Indonesian languages in Jawi script. The state of Aceh is almost exclusively islamic (and it applies the Sharia law). "Indonesian" (in fact a national standard form of Malay) is also official there, but Acehnese is more native with significant changes compared to standard Indonesian (both being commonly written in the Jawi script).

The Jawi orthography is not just for historic use, its usage is developping again almost everywhere in Indonesia (also in Malaysia, Brunei, as well as Singapore, the south of Thailand, and some islands to the south of the Philippines between the Sulu Sea and the Celebes Sea), notably because there's an official Jawi orthography adopted in 1986 for Indonesia and because the special Arabic letters needed for Malaysian languages are now well supported in the UCS and modern OSes, and by news editors, advertizers, TV channels, social networks; you can see dual script displays everywhere in Aceh, even on official road indicators.

Verdy p (talk)‎10:41, 11 February 2023
 

Acehnese language is written historically with Jawoe script. There are thousands of manuscripts written in Jawoe script since 17th century. It is still used until now especially at traditional Islamic schools. Some websites still use Jawoe script, for example this one: http://akhbarulkarim.blogspot.com/. And we intend to revive it again on Wikipedia.

Si Gam Acèh (talk)‎15:24, 11 February 2023
 
 
 
 

Please archive my talk page to allow me to use DiscussionTools

Edited by author.
Last edit: 09:14, 8 February 2023

Now that we can use DiscussionTools, I'd like to use it on my talk page. I do not have move permissions (and do not see a need to have them), so could someone with that right move User talk:Mainframe98?

Thanks in advance.

—Mainframe98 talk‎18:15, 7 February 2023

Done. There were some non-LQT discussions there which moved with the archiving. Feel free to move them around if you want.

Nike (talk)‎18:48, 7 February 2023

Great, thanks!

The non-LQT discussions are not important enough to bother with.

—Mainframe98 talk‎18:52, 7 February 2023
 

could the same be done for user talk:Álo?

Álo (talk)‎20:48, 7 February 2023

Done.

Nike (talk)‎06:52, 8 February 2023
 
 
 

Cannot translate

I cannot translate MediaWiki:Wikieditor-toolbar-help-content-ilink-syntax/scn. The new text that I want to submit is: 

[[Tìtulu dâ pàggina]]<br />[[Tìtulu dâ pàggina|Etichetta dû culligamentu]]
Ajeje Brazorf (talk)‎16:45, 7 February 2023

Done.

Amir E. Aharoni (talk)‎08:03, 8 February 2023
 

Request for temporary administrator right

Hello, I found a lot of optional messages translated on Serbian language which should be deleted. Examples are https://translatewiki.net/w/i.php?title=MediaWiki:Flexiskin/sr-ec, https://translatewiki.net/w/i.php?title=MediaWiki:Flexiskin/sr-el, https://translatewiki.net/w/i.php?title=MediaWiki:Timedmedia-derivative-desc-360p.webm/sr-ec, https://translatewiki.net/w/i.php?title=MediaWiki:Timedmedia-derivative-desc-360p.webm/sr-el and so.

There is a lot of them. I would love if I could get administrator right temporarily (on hour, two), so I can delete all of them.

Thank you for your understanding and consideration!

Kizule (talk)‎21:26, 7 February 2023

Even better on one day if it is possible. :)

Thank you for your understanding!

Kizule (talk)‎02:12, 8 February 2023

Done.

Nike (talk)‎06:56, 8 February 2023

Thank you, I'll make sure that I don't do anything bad. :)

Kizule (talk)‎06:57, 8 February 2023
 
 
 

"You can translate it in minutes!"

MediaWiki:Cx-uls-relevant-languages-panel-message/en has "You can translate it in minutes!" in it. Should this "minutes" be taken as 1-10 minutes, 1-30 minutes, or longer, or just "short, unspecified amount of time"? Could it be rephrased more clearly? I feel like 1-10 minutes would be too short even to review the translation of a moderately long article, not to mention revise. (I'm thinking about Wikipedia articles, but I'd imagine other wikis could have even longer articles, in which case even "a short time" might be unrealistic in general.)

MediaWiki:Cx-uls-relevant-languages-panel-message/ja is translated literally and gives the impression of "no longer than 1-10 minutes".

Note that not all languages have the idiomatic usage of "in seconds" and "in a minute" to mean "a short, unspecified amount of time". If the particular message is written that way, it would be helpful to have that clarified in MediaWiki:Cx-uls-relevant-languages-panel-message/qqq.

whym‎08:35, 31 January 2023

The time it takes to make a translation can vary a lot depending on the length of the article, how much the initial machine translation has to be edited, and whether the user is aiming for a complete translation or just a starting point (to be improved in further edit sessions). The idea to convey is that it is possible to make a meaningful contribution in a "short, unspecified amount of time". Of course people can dedicate more time and make a longer/better initial contribution, but if you have 15-30min available it is possible to make a small but valuable contribution by translating a short article or expand an existing one with a short section. I hope this context is helpful to convey this message in the way that best suits your language.

Pginer (talk)‎09:23, 31 January 2023

Thanks for clarifying. It looks like there are two main things to say in it. 1) We invite you to translate it. 2) It [the translation] won't take a long time. For me, breaking it down like that would make it easier to translate. Would a similar rephrasing make the English message awkward?

In any case, I'll probably avoid mentioning "minutes" in my translation because it will make it unnecessarily concrete in any phrasing I can think of in Japanese.

whym‎09:18, 1 February 2023

You are right on the information points to deliver. However, we try to make the message short and positive. For example, "It won't be long and boring" seems less encouraging than "It would be fast and fun". Translation removes many of the barriers required to make a great contribution (you don't need to master all policies, just to write the same thing you are reading in another language you know). So I think it is appropriate to provide a bit of encouragement in this case.

Pginer (talk)‎15:25, 1 February 2023

I see, thanks. I don't have much to add to this discussion any more, but I want to make sure it can be referenced when someone has a similar doubt. Should I link Thread:Support/"You_can_translate_it_in_minutes!" from MediaWiki:Cx-uls-relevant-languages-panel-message/qqq?

whym‎05:22, 5 February 2023
 
 
 
 

Request for the enabling of Hassaniya in TranslateWiki.

I'd like to be able to create a Hassaniya Wikipedia and for that I need to localise it. I've provided arguments already on Meta Wikimedia. Thank you!

Tidsaleh (talk)‎19:12, 27 January 2023

See Portal:Mey (disabled for now, I cannot enable it myself, its activation status can be checked at the bottom of Special:ActiveLanguages/mey). Also for now the existing Wikipedia Incubator portal is just an empty page, and there's no other known wiki natively supporting the language or containing related contents.

Note that in Senegal, there's an orthography based on the Latin script (like also the Wolof language, which influences Hassanya there), officialized by a national decree for a recognized minority. That variant (officially named Hassaniya in the Senegalese decree published in French, and spoken notably in the Goxumbaac or Gokhou-Mbathie quarter, to the North-West of the the national capital Saint-Louis) is still not well studied even though it is reported to be in high development in Senegal where it is also understood by local wolof speakers: it is missing in Glottolog/Linguist List, and not encoded separately in ISO 639/BCP47 with the two scripts (may be it could get a separate language code if efforts are made for it in Senegal if the contacts with wolof and French speakers, and the sedentarisation of former nomadic Maure peoples where they originated, has significantly modified it).

Elsewhere, most Hassanya people are in Southern Morocco, Western Sahara, Southwestern Algeria and Northern Mali, using the Arabic script for some poestry, but the language is mostly transmitted orally. Hassanya is considered part of Maghrebi Arabic, but it's a bit creolized with influences of Atlantic languages (mostly Wolof but as well other Mauresque languages), Berber languages, plus some Spanish (reports are saying that it reached the Canary Island, but I don't know its current vitality there, whereas it has reached Continental Europe in Spain and France, and other Maghebri countries with modern migrations, but their local populations don't seem to use it actively).

Verdy p (talk)‎01:29, 28 January 2023
 

This is now enabled.

I've added a list of recommended projects for translation to your user page.

Amir E. Aharoni (talk)‎09:57, 30 January 2023
 

MediaWiki:Tutorial-popup-text2/en

Edited by author.
Last edit: 21:55, 28 January 2023

Because of grammatical differences, I find this line very difficult to translate in Bengali. The whole sentence is: "You can turn previews on and off in the search preferences." (You can test this new feature on pt, id & ruwiki, when you first use search feature this popups) However instead of whole sentence, half sentance was given. Current Bengali translation looks like this: "আপনি অনুসন্ধানে পূর্বরূপ চালু ও বন্ধ করতে পারেন পছন্দ." but should be "আপনি অনুসন্ধান পছন্দে পূর্বরূপ চালু ও বন্ধ করতে পারেন।"

My request is instead of half sentence, give full sentence to translate please. Something like "You can turn previews on and off in the search [$1 preferences]." (also include ".", so i can use correct character in my language, not every language use . as full stop)

Then, this. In Bengali "In Wikimedia Commons" will come first and "View more" go second. See this "I rice eat" example to see what I mean.

Thanks.

আফতাবুজ্জামান (talk)‎01:24, 27 January 2023

Good catch! I reported the first issue at https://phabricator.wikimedia.org/T328108

About "View more", I'm not sure that it can be fixed in translatable messages, because these things appear separately. If I understand correctly, "View more" is a title of a list, which can (probably) have more than one item.

Amir E. Aharoni (talk)‎07:33, 27 January 2023

Thanks for the report :)

আফতাবুজ্জামান (talk)‎21:49, 28 January 2023
 
 

Request for the enabling of Hassaniya in TranslateWiki. (2)

Edited by another user.
Last edit: 01:47, 28 January 2023

(duplicate message, already sent in Thread:Support/Request for the enabling of Hassaniya in TranslateWiki.)

Tidsaleh (talk)‎19:12, 27 January 2023

Translations that don't use plurals are marked outdated

Toki Pona doesn't change words for plurals, so all the Toki Pona translations of strings that use {{PLURAL}} in English don't use {{PLURAL}} in Toki Pona. But this seems to make the strings all show up in the Outdated tab. Is there a way to get them out of there so we only see genuinely outdated strings?

Tbodt (talk)‎03:09, 26 January 2023

I recommend simply adding PLURAL with one value most of the time.

Occasionally, PLURAL used in non-trivial ways where the text is totally different for different numbers, and it's good to keep the automatic validation for such cases.

Amir E. Aharoni (talk)‎07:18, 26 January 2023

I see, thanks.

Tbodt (talk)‎18:35, 26 January 2023
 
 

Remotetasks

What are Test Questions? Why are Test Questions important? What if a Test Question is unfair? What are Quiz Mode and Work Mode? What is accuracy? Which jobs affect my accuracy? What can I find on my Contributor Dashboard homepage? What are Levels? Index of Appen Terminology Why are contributor accounts removed from the platform?[translatewiki ]

Hamdisaif (Contribute)‎23:26, 8 December 2022

Sorry, I don't understand your questions. What are you trying to do, and what doesn't work?

Amir E. Aharoni (talk)‎12:42, 10 December 2022

How can work remotely on small tasks like translation as so on? That is what I mean in the previously!

Hamdisaif (talk)‎18:51, 25 January 2023
 
 

Request to enable: Hindko

I would like to request that either of the codes hno or hnd be enabled for translation on TranslateWiki. The two codes for this language are "Northern Hindko" and "Southern Hindko," however the dialects of the language do not map clearly to this geographic distinction. Awankari, a dialect of the south, may be grouped with Kohati, a dialect of the north, while Peshawari and Abottabadi Hindko are spoken at roughly the same latitude. It is preferable that one code is used—it does not matter much which—to support a translation which may represent the features of the language common across the various dialects. Something I noticed when looking at the portal pages for these codes is that they each have an incubator Wikipedia, on which there is a single page which is identical between the two.

Resources and references: Hindko in Kohat and Peshawar is a paper which offers a helpful overview of Hindko dialect geography. The dialect it does not touch on, Hazara Hindko (dialect of Abottabad), is covered extensively in Halil Toker's Hindko grammar and in Elena Bashir's descriptive grammar. Hazara Hindko may be considered "northern" for what it is worth and is the most spoken dialect if that is any reason to pick one code over the other. The most comprehensive account of the Awankari dialect is Lahndi phonology by Hardev Bahri. There are a few dictionaries of Hindko, most only in print, but Peshawar based Gandhara Hindko board offers one as a mobile app. (I have a few of their Hindko apps on my phone and I suspect they just use the Urdu language code due to lack of support from Android. The number of resources online for the language is definitely ahead of where various tech platforms expect it to be.)

I will give full disclosure and point out my background is Punjabi, which is a language mutually intelligible with Hindko (in a similar sense to Norwegian and Danish by analogy). I have translated the Lexeme Forms message group in a way that is grammatical in both languages in order to support the Hindko templates there, however, this was only possible due to the message group being small and domain specific enough to do things like avoid feminine nouns entirely (they inflect differently between the two). It should be possible to attract more translators once the language is available as an option.

Bgo eiu (talk)‎03:10, 25 January 2023

OK, for the sake of simplicity, I'm going to add it as "hno", and with the autonym "ہندکو". If anyone ever asks to distinguish them, then we'll figure something out.

Amir E. Aharoni (talk)‎09:41, 25 January 2023

Excellent, thank you! I am glad it isn't too much trouble to make this work.

Bgo eiu (talk)‎11:52, 25 January 2023

This is now enabled.

Amir E. Aharoni (talk)‎15:31, 25 January 2023

Note that [hno] (Northern Hindko) is for Hazara Hindko (also called Kagani or Kaghani), whereas [hnd] (Southern Hindko) is grouping the four dialects of Attock, Kohat, Central Peshawar and Rural Peshawar (distinguished in Glottolog and the Linguist List, but not in ISO 639).

Both use the same Arabic script, and if they seem to be written the same, that's probably because of minor phonologic differences, and the written form in Arabic may not mark these differences explicitly with diacritics for actual vowels or voewl qualities, or alterations of consonants. The difference may be more evident in the spoken language.

The current autonyms written in Arabic script also still does not show these distinctions between [hno] and [hnd]; as well Hindko languages seem to form a continuum, both being part of the Lahnda macrolanguage (in its Northeastern branch according to Glottolog) in ISO 639, that macrolanguage also covering the more distant Khetrani (actually a Sindhic language), also written with the Arabic script.

Verdy p (talk)‎18:24, 25 January 2023
 
 
 
 

ماهي المواضيع

محرر== صفحتي ويكيبديا ==<refhamdikhalidsaif Hamdisaif (talk) 14:37, 25 January 2023 (UTC)=/>

ماهي "المواضيع والمهام" التي يمكن أقوم بترجمتها أو تصنيفها أو وصفها او كتابتها أو تعديلها أو رفعها أو نشرها لمساعده الاخرين على صفحتي والحصول بالمقابل لقاء عملي؟ Hamdisaif(ت ع م)

Hamdisaif (talk)‎14:37, 25 January 2023
First pagePrevious pageNext pageLast page
Retrieved from "https://translatewiki.net/w/i.php?title=Support/LiquidThreads&oldid=11446275#ماهي_المواضيع__62387"