Support

[Show old archives]

Support — 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)

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.

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?

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]

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".

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).

Thanks for your attention.

Wp/sro. The translation of MediaWiki (most important messages)is 86% and within a few days we will arrive at 100%. The translation of some other programs has already begun. We ask which programs we should prefer. Thank you.

You can do anything, but personally, I recommend following the list I put on your user page, from top to bottom. If there several people working on translating into this language, each person should work on a different item.

I also recommend making a list of namespaces. See the section about namespaces on the page Translating:MediaWiki. You can simply send it as a response to this message.

Finally, would you like to use any language as a fallback? Sardinian (sc), Italian, or anything else? Or just show English if the message is not translated?

Wp/sro. Hello, the translation of MediaWiki (Most important messages) in Campidanese has been completed, and we're proceeding with the items in the order that you suggested. We will shortly send you the list of namespaces too, as you requested. I also ask you if, at this point of the translation, it is already possible to have Campidanese (sro) as one of the interface languages or if it is requested a minimum percentage of total translation in order to have it. Thanks for your attention

Hello, these are the tables of the namespaces, with the translation of the names in Campidanese Sardinian (sro) on the first column.

Logus-nòmini de fundamentu

Nòmini de su logu-nòmini	Description
Mèdius	This doesn't mean "journalism". This is short for "multimedia". This is a general name for various media files stored in a common media repository. For example: image file, audio file, video file, etc. This is quite technical and rarely used, and may simply be transliterated or left untranslated.
Spetziali	This is an adjective. It's a namespace for special pages, which cannot be edited by users. They provide various services, such as display of information about the wiki, Recent Changes, Watchlist, Statistics, and special administration and editing interfaces such as Blocking, managing user rights, Translation, etc.
Arraxonus	The talk page for the main namespaces. Talk pages is where discussion about other pages takes place.
Impreadori / fem. impreadora	This is a user of the wiki. If there are masculine and feminine forms for the word "user" in your wiki, it's possible to add both.
Arraxonus de s’impreadori/a	This is the talk page of a user. It's used for discussing things directly with a person, whereas article talk pages are for talking about an article.
Arraxonus de Wikipedia	This is for talk pages where the wiki site's internal administration pages are discussed. "Wikipedia" here is just given as an example because Wikipedia is often (though not always) is the first site in every language. It can also be "Wiktionary talk", "Wikisource talk", etc. In the namespaces translations file, it appears as "$1".
Documentu	A file, usually photos, videos, music, and PDFs. These pages show the file and some information about it. For example, File:Viang Xai, Laos - panoramio (3).jpg.
Arraxonus de su documentu	A talk page for discussions about the file.
MediaWiki	Each pages in this namespace stores a translatable message. If a page exists, its content overrides the translation in the source code and in translatewiki. This is a name "MediaWiki" and it must remain recognizable, so you must not translate the word "media", but you can adapt its spelling to your language.
Arraxonus de MediaWiki	A talk page for discussions about the message in the MediaWiki namespace.
Mòlliu	A piece of text or code that can be embedded in other pages. Common examples of templates are infoboxes, citations, tags at the top of the article, etc. For example, Template:Citation needed and Template:Infobox writer are popular templates in the English Wikipedia.
Arraxonus de su mòlliu	A talk page for discussions about a template.
Agiudu	This is a namespace for help pages, which explain the users how to use the website. For example, the page Help:Table in the English Wikipedia explain how to edit tables.
Arraxonus de s’agiudu	A talk page about help pages.
Categoria	These are pages that describe a category that includes other pages. For example, the Wikipedia articles about Leymah Gbowee, Andrei Sakharov, and Alva Myrdal all belong to the "Nobel Peace Prize laureates" category in the English Wikipedia, and are automatically listed on that category's page: Category:Nobel Peace Prize laureates.
Arraxonus de sa categoria	A talk page about category pages.

The following namespaces are used in extensions that are installed on many wikis, and should be translated as well:

Logus-nòmini de is alladiamentus

Nòmini de su logu-nòmini	Description
Còdixi mòlliu	Modules are pieces of code that can be embedded into pages. They are similar to templates, but they are written in a programming language and not in wiki syntax.
Arraxonus de su còdixi mòlliu	A talk page about a module.
Aina	Gadgets are pieces of JavaScript code that can be written on a wiki site by the site's editors to enhance the site's functionality. They are stored as wiki pages.
Arraxonus de s’aina	A talk page about a gadget.
Definidura de s’aina	The gadget definition space is used for configuration metadata about a gadget.
Arraxonus de sa definidura de s’aina	A talk page about a gadget definition.
Pàgina	In Wikisource sites, the page namespace shows a single page from a file that represents a book, such as PDF or DjVu, and allows people to transcribe it to a digital text.
Arraxonus de sa pàgina	A talk page about a page.
Inditu	In Wikisource sites, the Index namespace describes a file that represents a book, such as PDF or DjVu, and maps between page numbers and different parts of the book.
Arraxonus de s’inditu	A talk page about an index.

Thank you for attention.

Hello, I would like to change the "page" term on Banjar Wikipedia which has been using "tungkaran" to "laman" based on community agreement. Please follow up.

Hello Ezagren, for which message exactly? Is there a special context? And what is the differenct between "tungkaran" and "laman"?

For "Main page" message and its derivatives. "tungkaran" means 'yard', and "laman" means 'page'. When translating the equivalent of "page" for Banjar message a few years ago, the community has not found the translation. However, the most recent Banjar Dictionary published by the official local government agency lists "laman" as the translation for "page".

You can probably simply change it in the messages. Just open the MediaWiki group, go to the "Translated" tab and edit all the messages where it appears.

You can also use Special:SearchTranslations.

Thank you for your translations into Banjar!

Thank you for the advice. However, when I edited a message containing the word "main page" and its derivatives, it was rejected because a warning message appeared stating that my edits were potentially damaging and needed support.

Oh, I understand. Yes, Main page is a bit sensitive. Where was the discussion about it, resulting in community agreement? I want to be extra-sure before changing it.

I found that in languages like Chinese and Japanese that do not have plural syntax, if English adopts {{PLURAL:, Chinese and Japanese must also adopt {{PLURAL: to pass the check. I wonder if it is permissible to not use {{PLURAL: for languages that do not have plural syntax?

You may still use a dummy . What is needed is not the PLURAL itself but the reference to the given variable somewhere in the string. This occurs as well in languages using plurals, because the translation may not even use distinct forms for some names or on conjugated verbs which actually do not vary with the numeric value of that variable.

The same is true with GENDER with the given variable specifying a user name, if it does not influence a translation.

But I agree that TWN should not warn on missing variables if they are used only in the first parameter of PLURAL or GENDER, and the target language is not defined with distinguished forms for plural or gender forms. Ideally there should be a way to expliclty state that these varaibles or not used (TWN would place them in a special "unused varaibles" comment attached to the translated unit, rather than in the text of the translated message itself (this would allow proper review and validation.

The alternative is for the target project to use a validator when processing the exported translations, to "cleanup" the unneeded plural or gender marks, or when the syntax {{PLURAL:varaible|forms...}} only lists a single form (it could drop this syntax, keeping only the single default form.

Ideally as well, translation projects should be allowed to list variables whose usage is optional (not required in the message itself). But for now the Tranlate UI assumes that if a varaible is used in the English source, it is also needed as well in all translations, and it should also allow listing variables not used in English, but needed in translations and supported by the target application that will provide a suitable value for them.

But for now a dummy use of PLURAL or GENDER is still needed for the listed varaibles whose usage is not necessary

Replace "as as" by "as a" in

Hold revision as as draft.

Suppress the duplicate "this" word in:

You can not plan changes to this this revision because it has already been closed.

Hello there,

I've found four special pages related to the GrowthExperiments extension that do not have Polish names:

• Special:EditGrowthConfig → Skonfiguruj funkcje dla nowicjuszy (with a possilble alias: Skonfiguruj Growth)
• Special:MentorDashboard → Panel przewodników
• Special:NewcomerTasksInfo → Zadania dla nowicjuszy
• Special:QuitMentorship → Rezygnacja z przewodnictwa

Since I'm not sure what project to tag on Phabricator, I'm writing here.

I will submit a patch soon. While preparing I found that another special page exists:

Special:ManageMentors => [ 'ManageMentors' ],

Could you translate this for completeness too please?

It would be Zarządzaj przewodnikami

Thank you in advance

Gerrit:805876 pending review.

And it was submitted last night. Will go live probably next week.

Thank you

I made this message (and more) a month ago MediaWiki:Prefs-centralnotice-display-banner-types/sr-ec; they aren't showing up

CentralNotice is following a different deployment schedule and it is not in our control. According to https://www.mediawiki.org/wiki/Developers/Maintainers it is maintained by Fundraising Tech.

Ok, i will ask them

And may be it was translated too late. Notifications will normally be updated after they are sent, even if they are viewed later (unless their content is generic enough to be generated by a translatable template, reusable for muliples notifications sent at different times, and using generic parameters like links or date/time that don't need a translation by themselves).

However this translation was for the panel for managing notfications, it was not part of a notified content, so it should be reusable. Lot of works are being done on how to manage notifications and deploy them to various wikis (or other communication channels): if may appear that this message was actually not mathcing the same part of the deployed system, if a targert wiki uses some other controls that are stiull not integrated. So it is interesting to know on which wiki you do not see this translation; the situation may be different in Serbian Wikipedia than other wikis (that may or may not also recognize the legacy "-ec" variant code used in interwiki codes on Wikimedia wikis only, but that is not conforming to BCP47 where it should be "-cyrl"; so fallback rules may play a role here, as well as the tool used to deliver notifications, which may not recognize these legacy codes).

On srWiki & enWiki doesnt show up; tried different settings (ergo sr and sr-Cyrl)

Should replace "concerned" by "concern" in:

A commit has a concerned raised against it.

Hello! I want to enable magic word Grammar for Georgian language. What should I do in order to make the minimum cases available (sitename declination etc.)?

Excellent!

Just write the forms as a reply here, and I'll add them to the code.

Elementary declination I wrote here - Template:Grammar-ka. There are English meanings to. Is it easyto perceive?

OK, I'll do it. Give me a few days, it's a little bit complicated :)

The actual grammar for declensions and other word derivations in Georgian is quite complex: depending on word final letter it changes depending if it is a vowel or consonnant; but as well depends on a long list of exceptions; and propernames are treated specially); as well there can be a mutation or elision of the last vowel before the trailing consonnant. And there are many grammatical cases (including the "vocative" case, contested by several wellknown Georgian linguists, which applies to nouns or nominal groups that are not grammatically attached to a verb in a sentence or proposition and not attached to another noun as a genitive, dative or locative complement).

I looked inside Wiktionary (in Georgian, or in English and French that have extensive sets of templates to show tables of derivated words, like declensions, plurals and conjugation) or in Wikipedia, and for now this has never beend developped).

So before doing a change on translatewiki.net, you should first start developing a set of derivation tables in Wiktionary, enumerate and test the possible cases (this took a long time to develop for example in French, German, Italian or German, it was still messy to develop in English for conjugation of irregular verbs; as well the rules needed for Slavic and Celtic languages can be quite complicate: Georgian behaves much like Celtic languages, except that it does not seem to use mutations on the leading letters of roots) and then discuss it there, on how to integrate them with other wikis. This could take the form of a module rather than a template, but TWN still does not support Lua modules (with Scribunto), only regular MediaWiki templates.

However it may support an extension for the {{GRAMMAR:case|word}} by setting up an extension hook written in PHP and used by MediaWiki: you will need to contact MediaWiki developers for this, but generally such development starts only after setting up at least templates or modules (generally in Wiktionary where it can be tested and discussed and where lists of exceptions can be reliably developed and tested, instead of making assumptions on just a few words). So you should first contact users of Georgian Wikitionary to see how they can help on this project.

Later the Mediawiki PHP hook extension for grammatical cases (see mw:Help:Magic words#Localization and mw:Manual:$wgGrammarForms on the MediaWiki wiki, and the Language:convertGrammar method of the Language class, part of the "mediawiki-core" API in PHP on the Wikimedia documentation site) could be initiated. For now nothing has been done there for Georgian:

You'll need to think about the effect of other modifications based on the grammatical gender, or on the semantic type of names like inanimate/personal/honorific/conceptual (typical of various African languages), or based on the grammatical plural, or on the presence of contextual mutations and elisions, and make these part of the case selector parameter. As well the values of the case selector must be rationalized: generally, they use common abbreviation, they don't need to support "plain names" in Georgian, except as common aliases that may be optionally recognized/standardized, but this is probably not worth the effort and could cause confusion on how to use the "GRAMMAR:" parser function; so the case value could remain as plain abbreviations in ASCII/Basic Latin (like the "GRAMMAR:" function name itself). And for rationalizing that, you need good linguistic references for the target language (even native speakers do not know or think about all the needed cases to handle, notably about attested exceptions or derivation rules that are more complex than usual, and hard to think about without extensive searches, that's why I suggest basing the development and tests in Wikitionary, which should collect as many terms as possible).

The base documentation for linguistic conversion supported in MediaWiki is documented on the ILanguageConverter Interface Reference.

You'll also note that even wellknown languages like English (except very few things not related to grammar, basically only to handle fallbacks from other languages to English without producing errors, or for adding minimal experimental support for a fictive "Piglatin English" variant, only for the purpose of testing the support of "language variants" in other modules by developers knowing only English), French, German, Spanish, Portuguese, Italian, or Russian (fully documented in their own Wiktionary, and using sets of derivation templates or Lua modules) still do not even have a specialized class in Mediawiki for handling GRAMMAR)... That's because the maintenance cost of the GRAMMAR parser hook is much more complicate than just using templates/modules (on each wiki), and setting up a GRAMMAR parser hook support without maitnenance could potentially break a lot of pages (if they do not properly handle long lists of exceptions). The same can be said about the development of transliterators and input methods (difficult and already quite large to maintain for Chinese or Serbo-Croatian without an extensive user base and lot of discussion with a large enough team of supporting developers using reliable linguistic sources).

Hi! I implemented ნათესაობითი (genitive). For example, now you can try changing MediaWiki:Aboutsite/ka to say {{GRAMMAR:ნათესაობითი|{{SITENAME}}}} შესახებ, and it should work.

If it works well, let me know, and I'll do the rest.

I do not see the implementjation in MEdiaWiki core sources. To be actually usable in translations, given that these translations will be used on other wikis, it needs to be deployable.

As far as I see there's still no "includes/languages/LanguageKa.php" and "languages/messages/MessagesKa.php" is basic and just implements translations for namespace names, magic keywords, and a custom regexp for link trails, without registering a grammar extension.

It should be implemented like the grammar extension for Finnish, Irish Gaelic, Upper Sorbian, Kazakh (Cyrillic, Latin, or Arabic), Kölssh/Ripuarian, Latin, Ossectic, Slovenian, or Tuvian:

• https://doc.wikimedia.org/mediawiki-core/master/php/LanguageFi_8php_source.html
• https://doc.wikimedia.org/mediawiki-core/master/php/LanguageGa_8php_source.html (only specific words)
• https://doc.wikimedia.org/mediawiki-core/master/php/LanguageHsb_8php_source.html
• https://doc.wikimedia.org/mediawiki-core/master/php/LanguageKk__8php_source.html (detects the target script to use for additional variants per country)
  • https://doc.wikimedia.org/mediawiki-core/master/php/LanguageKk__cyrl_8php_source.html (actual implementation for the 3 scripts)
• https://doc.wikimedia.org/mediawiki-core/master/php/LanguageKsh_8php_source.html
• https://doc.wikimedia.org/mediawiki-core/master/php/LanguageLa_8php_source.html
• https://doc.wikimedia.org/mediawiki-core/master/php/LanguageOs_8php_source.html
• https://doc.wikimedia.org/mediawiki-core/master/php/LanguageSl_8php_source.html
• https://doc.wikimedia.org/mediawiki-core/master/php/LanguageTyv_8php_source.html

I don't know if you implemented it just to provide case overrides for specific words in a small custom dictionnary (just for Wikimedia project names, like in Irish?), or in a generic way (like in Kazakh, Latin, Slovenian or Tuvan) if there's a way to guess it from the detected forms.

Note that the links above are those used for the current documentaton of MediaWiki, they are probably not in sync with the current development branches, or the last deployment branches, or the last testing ("Canary" build) branch used on test wikis before the actual deployment in the master branch, or in a specific subbranch (only for Wikimedia wikis if your changes do not apply to generic MediaWiki).

If there's no specific per-language override for grammar in any branch, we just get a default fallback for {{GRAMMAR:case|word}} in Language.php which just returns the given word without changing it for any given case.

• https://doc.wikimedia.org/mediawiki-core/master/php/Language_8php_source.html

Also the recognized values for case given to {{GRAMMAR:case|word}} should be listed and documented. Unfortunately they seem to be non-generic: existing implementations use translated case names, and not generic abbreviations or English names for common cases like "nominative", "ergative", "vocative", "accusative", "genitive", "dative", "abblative", "locative", "adverbial", "prepositional"...), because otherwise these grammatical case forms won't work and will just return the unmodified given word. In some languages, even the case names are variable and may have known aliases, and their own local list of fallbacks from one case form to another. As well, the value to give for the word parameter is generally in the "nominative" case, but I wonder if that is always true for all languages (notably for proper names, the default case form is probably "ergative"); if we give the word in the wrong case form, the derivation of inflections may not work as intended.

---

Something that I'd like to have in French is a derivation pseudo-case form for elisions of the final vowel of leading articles ("le", "la"), or prepositions ("de", "jusque", "lorsque", "puisque"), or subject/object/reflected pronouns ("je", "me", "te", "se", "que"...), or negation particle ("ne"): there's a generic rule when the following word starts by a vowel (a,à,â,e,é,ê,i,o,ô,u,y) where elision is mandatory, but a lookup is needed in a moderately large dictionnary for words starting by a leading "h" (or at least a radical, or common prefix like "haplo", "hémi", "hém(a/o)", "hept(a/o)", "hétér(i/o)", "hom(i/o)", "human(i/o)"... which are generally unaspirated), because the elision of the leading article/pronoun/particle occurs only when the leading 'h' is mute in the following word/radical/prefix, not when this 'h' is "aspirated" (generally noted in French dictionaries by a leading asterisk in the phonetic notation of lexemes, most frequently nouns or substantive radicals like "haricot", or proper names and gentilés and people names like "Hongrie", "Hongrois(e)(s)", "Hun(s)", "Han(s)"... but not "Henr(i/y)"; but it may be possible to list these aspirated words as "wellknown" exceptions, but there are many "aspirateds" words that are in fact borrowed from other languages where the 'h' is not just "aspirated" and mute like in French, but pronounced with some leading glottal or voiced consonnant like "Haydn" taken from German: in general proper names starting by a capital 'H' are aspirated by default, except for a few know exceptions, so that no elision occurs for the common preposition "de", or rare article "le"). There also the very common (and mandatory) case of contraction of "le" or "la" (only if they were not elided with the following word) or "les", after prepositions "à" or "de", into "au(x)" or "du/des". Another case similar to elision is the mandatory transformation of the article "ce" into "cet" (not an alision but appending an epenthetic consonnant) in the same cases where the following word would require the elisition of a previous "le" or "de". The frequent epenthetic addition of particles "-t-" or "-z'" (purely phonetic, without any semantic meaning, but orthographicly mandatory) also occurs between a conjugated verb and a pronoun starting by a vowel ("il(s)", "elle(s)", "on", "en", "y"), when this conjugated verb ends with a vowel (even if that vowel is a "mute e").

Similar elisions occur in Italian (even more frequently than in French). Such very frequent uses currently have no support in MediaWiki (even if it is mandatory in the grammar) and thus requires adapting the translations in non-obvious ways.

For Celtic languages (Breton, Irish, Welsh...) the situation is more complex because there are mutations of leading consonnant(s) and possibly the following vowel.

For Slavic languages (Russian, Ukrainian, Serbian, Slovenian...) another complexity exists with proper names which have complex derivation (taking also into account the gender of the designated person): this leads to situations where translations made for these languages do not use normal sentences, but use a quite "ugly" form with extra punctuations and separators in order to "isolate" these names in an "ergative" form. The result is a non-natural translation using non-verbal sentences that look more like an enumeration of terms.

So for now the support of "GRAMMAR" transforms is really very basic, not very well studied, and a lot more development is needed to correctly handle all linguistic needs. The existing support may then be unstable. The existing basic syntax {{GRAMMAR:case|word}} may be insufficient, needing more parameters, e.g. for mutations and how to glue two terms, or for the placement of particles in the sentence, such as in German conjugations, but even in English with adverbial particles). In most cases it is simply impossible to derive terms or sentences correctly, and if possible, translation units should not fragment sentences (to also avoid bad assumptions about the correct word order, frequently made by English developers and causing troubles when we attempt to translate these "patchworked" messages), but terms that are very likely to be used as "variables" embedded in sentences and that are the most problematic are proper names (including user names, that must be properly isolated also because of Bidi, when we cannot even transliterate them or when they mix several scripts).

See https://gerrit.wikimedia.org/r/c/mediawiki/core/+/787720

I'll try and write if it works. Thanks for your interest.

@Amire80: Hi. I changed this - MediaWiki:Growthexperiments-help-panel-suggestededits-tips-vector-visualeditor-expand-main-value/ka - and it works (in genitive). Thank you.

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

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].

• Before: Localisation updates from https://translatewiki.net
• After: Localisation updates from https://translatewiki.net [skip ci]

Thanks in advance !

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

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).

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.

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.

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.

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.

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?

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.

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)

@Nike, your feedback on this would be appreciated.

I have captured the commit message customization request in this task: https://phabricator.wikimedia.org/T310142

For short term, would switching the commit mode from push-to-master to push-to-branch + automatic pull request help you?

Thanks Nike. I subscribed to the Phabricator ticket to stay informed of progress.

would switching the commit mode from push-to-master to push-to-branch + automatic pull request help you?

As far as I know, pull request submissions also trigger TravisCI builds, so I don't think that would make any difference in terms of credits consumption, unless there is a setting that can somehow prevent the builds to occur based on some criteria (user who submitted, branch name or whatever). I'll look into that.

Please do not change anything for now.

"Lock '$1 is not locked by this process!"

Missing closing quote after $1.

Is there a possibility that the fallback language of the Chavacano Wikipedia be switched to English? (I note that a previous request had been made in 2009: https://translatewiki.net/wiki/Thread:Support/Fallback_language_for_cbk-zam.wikipedia.org.) Though a Spanish creole, most speakers of Chavacano cannot understand Spanish (like most people in the Philippines), hence, many messages that have not been translated would be incomprehensible for those who speak Chavacano and may discourage people from editing. This Wikipedia is largely inactive.

Yes, I can do it.

However, I'd love to use this opportunity to also add namespace translations, because it's done in the same file. It's very simple! Read the "Translating namespace names" section on this page: Translating:MediaWiki#Translating namespace names. I only need translations for the words in the "Namespace name" column in the first table (but please read the explanations in the "Description" column before translating to make sure you understand them correctly).

Thanks :)

Thank you. I admit I am not a native speaker, though I can mostly understand the language.

The following translations are those that I believe are appropriate:

Media - Media Special - Especial MediaWiki - MediaWiki Template - Plantilla Help - Ayuda Category - Categoria

The rest I am not entirely certain as I am not a native speaker.

Is it still possible to switch?

It's possible, but can you please involve native speakers? Configuration changes of this kind are a major thing, especially for a language that already has a Wikipedia with an active community of editors. They may be difficult to undo if someone doesn't like it. For example, can you start a discussion about this on a community discussion page in the Chavacano Wikipedia and get some responses? Thanks for understanding :)

Good day, Would it still be possible to pursue this? I greatly believe that switching the fallback language would make the interface more understandable for potential editors. I have started a discussion at https://cbk-zam.wikipedia.org/wiki/Wikipedia_discusi%C3%B3n:Tambayan_De_Los_Chavacanos#Switching_the_fallback_language_to_English, although the Wiki is not so active so I am not sure how much discussion it would generate. If no discussion occurs, how should I proceed?

Many thanks.

I Mohammed bama i request for a new language bura to be included in the Wikipedia languages bwr as the language is not on the Wikipedia platform

There's an initial portal for it in Portal:Bwr, however it is still marked as a disabled language. Also I did not find enough info in Wikipedia and liguists list to determine accurately which script is used to write the language, which is spoken apparently by only about 250k people in Nigeria.

Two scripts are likely possible for this North Chadic language: Latin, or Arabic. Also I did not find any basic terminology list, so most probably it has no established orthography (which will have to be invented?). Note that in that case this creation cannot be done alone, as the language is reported to have a quite specific phonology for its lateral consonnants (according to the English Wikipedia article, but it does not give its sources). So the information is very parcellar.

In Wikipedia, there's a policy about requiring sources and avoiding self-creations or inventions. I doubt that a Wikipedia can be created for now (even inside Incubator). You should discuss about it with Wikimedia Incubator, and with people in the Linguists List. And if you have resources that can be used (facsimiles of published books/articles/poems, with legal copyright and licences allowing their reuse, as well as getting in contact with more people that want to support this development (e.g. an university department in Nigeria, or in other countries working in cooperation with Nigeria).

Note also that Bura should not be confused with the major Marghi (or Margi) language, which is very close and largely overlaps in the same region (but slightly more to the south), but is spoken by roughly 20 times more people in Nigeria. However Marghi (see Portal:Mrt) still does not have any active Wikipedia (also not any Wikimedia wiki, even in Incubator), and also does not have any support for now in translatewiki/net for any other projects. However Marghi is better described and studied, with many more available sources that owuld not be too difficult to find and use as references. I just wonder why such development for Marghi has not even been started (may be this could interest you as well, and it can find also support in other surrounding countries than just Nigeria, in Southern-Western Chad, South-Eastern Niger and Northern Cameroon).

This is enabled.

Start here: https://translatewiki.net/wiki/Special:Translate?filter=%21translated&action=translate&language=bwr&group=core-0-mostused

That user did not even reply about which script he would use: Latin or Arabic ? the highly related Marghi language (which is covering a large part of the same region, but extends also to other countries, has about 20 times more native speakers, and it is written in both scripts, including inside Nigeria itself (essentially in the two states of Borno and Adawara). Boura however is more local and apparently restricted to Nigeria (in the state of Borno only, but originally in a rural area with small vilalges, and it is likely that many of their sapeakers have related in more urban sectors, notably in the cities of Biu and Maiduguri, where there are much more native speakers of Marghi). If I look at the map of the areas where Marghi and Bura are spoken, it looks like they all use an official toponymy based on Marghi (or Hausa, which is also a Chadic language, but recognized officially, even if it has a simpler system of consonnants), now written in the Latin script, and they show no sign of the additional consonnants used in the Bura language (or clusters when written with the Latin-based orthography simplified by the use of the alphabet for English and Hausa).

Latin (private communication).

I am part of the OpenStreetMap.org operations team.

Please can the following be done:

• Remove: en-gb translation (it is widely out of date, has incorrect licence translation and causes us issues etc)
• Remove: All non english translations text from key intro_3_1_html and credit_2_1_html (And clear cache?), we changed EN a long time ago, but incorrect old translations were used in most cases.

Is there a better place I should be raising these issues?

Hi Firefishy,

Apologize for the delay in responding to this.

To confirm,

1. You'd like to have ALL en-gb translations removed
2. You'd like all translations for the following removed,

• • https://translatewiki.net/wiki/Special:Translations?message=Osm%3ASite.copyright.legal+babble.intro+3+1+html%2Fen&namespace=1222
  • https://translatewiki.net/wiki/Special:Translations?message=Osm%3ASite.copyright.legal+babble.credit_2_1_html%2Fen&namespace=1222

Regards,

Hi,

1. Yes ALL en-gb translations removed. en-gb is frequently wrong and en is close enough. 2. Yes both those items

Note that an exclusion of en-gb can be made project by project. You spoke about OpenStreetMap, this is something that should be decided by OSM themselves. If so , translations in the "Osm:" namespace can be disabled selectively without affecting other projects still using "/en-gb" and supporting it for specific subsets of messages (it seems that Wikipedia has specific specialisations, notably for orthographic convetions as the default is using American orthography, or because there are specific messages for users in UK , e.g. for fundraising with conversion of currencies, or some default conventions for measurements). In the content of Wikipedia articles however the rules are to be permissive on orthographic variants, and there are common templates to help display alternate mesurements (e.g. temperatures, in Celsius and Farenhieght, or road speed im mph or km/h), so that only the UI (which cannot use easily those conversion templates) can properly adpat a few messages.

There's a similar situation in French (but all communities havce decided that a single French version was sufficient, and translations are made so that they can fit well with all variants, and French is now very persmissive and open to variants in the normal language, so that they can be used interchangeably).

Another different situation exists in Chinese: the automatic conversion between simplifid nad traditional Chinese generally works well, but there's a specific Mediawiki syntax to support variants, including specific variants of Traditional Chinese for Hong Kong; however this syntax does not work for translating the UI, so the 3 variants are allowed; as well this is needed for translating projects that are not based on Mediawiki or where the MediaWiki parser is not used, e.g. in subprojects or modules actually written in Perl, Python, PHP, Java, or C/C++)

In the Mediawiki namespace (that contains hundreds of message groups), not all messages are based on the MediaWiki parser. And it's difficult to isolate these message groups; so translations are still opened but MediaWiki modules may choose to use (or not use) specific message groups using variants (idfeally we should have a way in TWN tyo track these groups, so that translators are not bored seeing so many "untranslated" messages, and don't loose time trying to "fix" them. In general, variants should be avoided as much as possible, by making base translations (in "/en") suitable worldwide.

Note also that some base translations which should be in English sometimes contain typos or bad terminology that need to be corrected, however chaing them requires also changing or reconfirming all translations. This is problematic: such fixes of typos or orthographies should not require reconfirming all translations, so translating in the "/en" locale should be permitted (and if such translation is made, this should be displayed in the translate UI each time there's a different version between the base and the "/en" fixed message, so that '/en" will provide a better hint; but without forcing all other translations to be editing or reconfirmed (so the base source of translation may still contain "errors" that should not need to be fixed when only fixing them in "/en", as if it was a variant, should be sufficient. This would limit the number of messages translations that need to be reconfirmed in ALL locales (for example is a source was changed to use "colour" instead of "color", or if a comma was added or removed before "and", these are cases where other languages are not concerned at all: enven British English has several conventions about if they prefer Oxford recommendations or not; it may be good to unify the orthography and conventions in the English locale, but this is local tuning and should not affect other languages using their own conventions about this; the same will be true about how dates are displayed, with day number before or after the month name, and year appended without a comma separator in the first case, but with a comma in the second case, usually prefered for US only, but not Canada, Britain or Ireland).

Messages that need to be really fixed in the base source are just those that are too much ambiguous or misleading: only those need then to be retranslated/reconfirmed in other languages, but minor typos fixed in English should not impact all other translations. This is not jsut a TWN problem, but a problem about how each project manages its source translations. But TWN should offer a way to mark source base messages that were reimported here for just fixing minor things. Ideally projects should be able to use fixes made directly in the "/en" variant (which should then be opened, even if we close the "/en-gb" variant). Such examples of messages include those for projects that were actualyl created by developers whose knowledge of English is insufficient (e.g. projects supported by Chinese developers, which contain frequent English typos or a strange linguistic syntax which is hard to understand even for native english speakers or for all other translators that attempt to decipher their actual meaning).

Note also that source English message do not always need to be fixed: we can add documentation about the meaning or some restrictions applied, inside the "/qqq" doc (including for adding links to specific support pages, tracked bug reports, or to external community talk pages or decisions, votes, terminologic lists, or more info), so that translators can be properly guided when they translate to other languages and so they can evaluate if these external pages need to be follwoed as well or not for other languages): the source base language is generally not sufficient and does not necessarily have to be followed too much strictly.

Láadan is a constructed language (while checking to see if portal:ldn already existed, I found it was linked to by languages by language family/Artificial so I see TWiki considers this a relevant consideration for languages) with an Incubated Wikipedia, a set of dictionary entries, several source texts, a libre grammar, and various media hosted on Commons. Outside of the Wikimedia sphere, it is used for comics, music, and zines (among other applications as a general-purpose language).

Yes the Portal:Ldn was linked (but did not exist for now, like with many languages with assigned ISO 639 codes: the pages for "languages by family" are there to help locate languages and related languages, to find relevant ones and avoid confusions of codes for such creation, or incorrect use of codes; that's why those links are shown in red in these lists until the effective portal is created, because someone wants to register as one user of that language, not necessarily as a translator for a supported project).

I have made the initial portal and categorized it (because there's an attempt to create a Wikipedia Incubator, though it is almost empty, however there are terminologic lists and documents stored in specific categories of other Wikimedia projects).

If you want indicate that you understand it, you can still register it in your user page (inside the {{#babel: ... }}); If you want to support that language and want to become one of its future translators you can register yourself inside the portal.

However to support it, there's a need to have maintainers with real translators working in a team (or wanting to create suich a team, i.e. accepting to not work alone). You should contact contributors that created glossaries in other Wikimedia projects. The external wikipedia:en:Láadan page gives a list of contributed contents at end, visit them and see if you find interested people for creating a translated UI for MediaWiki, not just for Wikimedia projects but any wiki including possible "wikizines" (hosted for example in FanZone, formerly wikia, but note that Wikia itself is no longer supported directly here, except for the MediaWiki core and standard extensions), or eventually for other projects which are (or could be) supported by translatewiki.net (including other wiki hosting providers like BlueSpice).

I cannot enable it myself in the Translate UI (only a site admin can, and will reply below if this is done). So for now the portal and its related categories is still marked as a "disabled language"

(notably the |no-15924=1 parameter in the Portal template is there to avoid linking its default script (Latin) to the Translate UI, where it would still not work and would instead start proposing translations to another unrelated language, and would pollute it).

You can check if the language is enabled (in the Translate UI of translatewiki.net) by looking at the bottom of Special:ActiveLanguages/ldn. Only when this will be enabled, can these markings for "'disabled languages" be removed from the portal and its category or subcategories.

Thanks -- I have added my babel code* to my user page (and at Metawiki also so it shows up on various sister wikis) and plan to add myself to the portal when possible, and I emailed some fellow Láadaná I've been in touch with before (and searching the net for skilled others is also a good idea). Now I'll wait for a site admin to see this thread.

*Looking forward to translate the strings for this in particular, although I wonder about the -N variant for languages with no proper native speakers like Láadan (although some of my fellows I believe would handily count as ldn-4). edit: I see localisation guidelines#Translate, don't customize so I presume such concerns are beyond a given task of translating?

P.S. Did you mean Fandom? I don't see a FanZone in search results that looks relevant.

Yes I meant Fanzone (the successor of defunct Wikia, whose support was ended here as the new company refused any communication; we don't know how they've tuned Mediawiki for their local use; but if they translate something, they do it by themselves or with their own tools, or via their own support)

(phab: ticket for the WD side: phab:T302705)

Hello! I would like to change my username to User:Diskdance, in order to keep consistent with my Wikimedia account. Thank you!

 Done

Please, remove translation rights from Enly M [ talk · contribs ]. He/She is editing/creating blatantly wrong translations in Spanish. I've left a message in his/her talk page pointing out examples of the errors.

@Ciencia Al Poder: Done. Should I delete their contributions as well, or should I leave them so they can be fixed?

Most of them are correct (maybe because of its simplicity). I can take a look at them. Thanks!

I request that unlock it so that can continue working on the Tai Nüa (tdd) translation, I would like to tell the admins not to ask about my level of education in this translation, I do not like it, so I think talking about education level is a brag. I'm a multilingual research writer, so I know my educational level, so I don't want to tell anyone about my level of education. I came to wiki to promote outdated languages, can see my activity on wiki at the following link. I will do my best for this translation as long as I have time, thanks.

Hi,

This is done. For MediaWiki, start at https://translatewiki.net/wiki/Special:Translate?group=core-0-mostused&language=tdd&filter=%21translated&action=translate

I won't ask you how much do you know this language, but I do strongly recommend that you involve native speakers in translation as much as possible.

Thanks.

Suggestions panel in the translation UI - The direction is incorrectly set to RTL instead of LTR for the suggested text (so the final punctuation appears incorrectly to the left instead of the right, and its start margin is incorrectly set to right instead of left).

Note in this image, this is for translation to French (which should be LTR). In fact this is also reversed when translating in all other languages.

The direction and alignment is correct on the rest of the panel, only the "Suggestions" part is affected

Does this still happen? Where do you see it?

It seems to no longer happen; it was the case when I posted this message (on 23 May) in EVERY translation (to French, Italian, Spanish...) for any message in any transltion project that was showing "Suggestions". And when I switched to translate to Arabic or Hebrew, the "Suggestions" where also swapped (LTR instead or RTL). So there was a bug in the UI (or in the CSS stylesheet) inversing the RTL/LTR conditions for styling this pane. I did not inspect the CSS with the browser's developer tools to notice how it was styled.

It is OK now, so I supposed it has been fixed (but there was no reply to this topic when this was done, may be you detected that bug yourself and fixed it without seeing this report, or because you saw another bug report in another channel, possibly in Phabricator, or on another wiki using the translation UI, which was updated recently to add a section about "Recent modifications" to show the last few edit comments).