Support

From translatewiki.net
(Redirected from $support)
Jump to navigation Jump to search
NoteSupport — Problems? Questions? Suggestions? Write your message below. — See also the FAQ or try to catch us in IRC or in Telegram.
Your request has been forgotten? Feel free to post a reply to bump the thread to the top. Very old threads have been archived.
(The thread summarization feature is broken, see Phab:T245109.)

Contents

Thread titleRepliesLast modified
Babelbox stylesheet refresh.016:09, 1 October 2022
Remove fuzzy tags302:54, 30 September 2022
OpenHistoricalMap (OHM) translations needing a review319:35, 26 September 2022
Standardized message for "Translation administrator"108:34, 26 September 2022
Admin edit of MediaWiki:Feedback-termsofuse/pt219:29, 25 September 2022
Adding a new language, ISO 639-3: ldn (Request)406:50, 25 September 2022
Enable Terminology gadget by default?323:19, 23 September 2022
About Phabricator:arcanist-core-3119f17b3b50c21d/en322:37, 21 September 2022
Adding Phorge for translation?106:43, 13 September 2022
Translations that I cannot change myself221:02, 12 September 2022
Portal:Acm107:31, 12 September 2022
GENDER purposes107:31, 12 September 2022
Please delete this page420:18, 10 September 2022
Saraiki language ?409:09, 9 September 2022
Registering an extension fork – partial message key collision416:09, 6 September 2022
Change Username109:53, 3 September 2022
Is there a process to pause the call for translations ?219:24, 2 September 2022
Change Username 114:56, 1 September 2022
OpenStreetMap.org Translation Fixes522:00, 31 August 2022
Where is project ?617:32, 31 August 2022
First page
First page
Previous page
Previous page
Last page
Last page

Babelbox stylesheet refresh.

Some Babel boxes do not display properly with some language codes that are a bit overlong (e.g. Chinese script variants, but as well "gsw-1") and span too many lines, increasing their height too much. There problem is within the default stylesheet which uses too a large font, a default too large line-height, and an additional padding that is not needed at all, and can safely be reduced horizontally. As well the text content should be reduced to match the box height.

Visit for example user pages that have "zh-hans", "gsw", or "roa-tara" in their "#babel:" user boxes.

You can make this test by using this CSS in the "/common.css" subpage of your user page (like I did on my own). This allows codes to be written on 3 rows without increasing the box and preserves the general layout of Babelboxes so that they line up correctly

.mw-babel-box table th { font-size: 15px; line-height: 1; padding: 0 1px; }
.mw-babel-box table td { font-size: 11px; line-height: 1.4; padding: 0 1px; }

Then look at Babelboxes shown on these user pages. (You can test it with other supported skins, if you place it in your "/common.css" subpage of your user page, where it applies the style to all skins; but you may want to limit it just to the default Monobook or Vector skin by placing it in your "/monobook.css" or "/monobook.css": the links of these stylesheets are available in the "Preferences" page for each user, in the "Appearance" tab).

The most language codes will now display on one row; 2 rows will be used for language codes have 3 letters in their base code, but without causing the box height to increase, and a 3rd row can still fit if there's a script variant like "zh-Hans-N". Only very few codes will eventually fit on 4 rows, causing the Babelbox to increase from their minimum height (45 px). The style above make sure that the line-height for the code is 15px (like also the font-size, which is safe because we only display Basic Latin letters or digits here), and also allows the text to use up to 3 rows (15px each, given their line-height of 1.4em which is readable on all scripts for the short description texts in Babel boxes).

This should in fact be part of the default site stylesheet.

Verdy p (talk)15:49, 1 October 2022

Remove fuzzy tags

Hello. I would like to remove the fuzzy tags from MediaWiki:Wminc-custom-newarticletext-withprefix-4/sl since otherwise, the message appears among new untranslated messages. (The spurious links are marked as translatable in the message description.) How can this be done? Thank you.

Eleassar (talk)00:19, 30 September 2022
Edited by author.
Last edit: 01:59, 30 September 2022

Problem solved ! The target of the link (that needs the "Wx/xx/" prefix, which should not change) is different from the displayed text (where the prefix is undesired and will be translated).

So you can leave that target link part untranslated, and translate the text after it.

  • Note that this is caused by the fact that translatewiki.net wants us to keep the link, even if it is within a "nowiki", and does not work as a link. But in fact even in that case, the message should provide the expected way for editors in Incubator, that most often, cannot use the reduced fom of wikilinks with the the target page name not being what is wanted in the rendered text of the article. This is a problem of translatewiki.net that overvalidates messages containing wikilinks (effective, or simulated like in this case): it does not accept that we change the target of hyperlinks in translations (even if it is "safe" here).
  • Another way to solve it would be that the message contains a placeholder "$1" for the link target (the underlying app would insert the appropriate target link with a string containing ONLY the target page name, which we could translate isolately, and not containing the double-brackets delimiters.

Note for now that all we can do is to keep the target of the sample hyperlink unchanged, and not use the compact form of the hyperlink (with no pipe), which is most likely never used in Incubator pages (and then should not be displayed as good examples in such messages). In my opinion, even the English source message should not display compact hyperlinks (with no pipe), but always use their in their expanded form (with a pipe) which is what will be almost always used in Incubator pages.

Verdy p (talk)01:28, 30 September 2022

Thank you for resolving this and the explanation.

Eleassar (talk)01:34, 30 September 2022

There are similar problems with hardcoded hyperlinks in this module, such as:

Here the two hyperlinks should be tunable as well by providing a separate translation unit containing only the target page name, pointing possibly to some other article on another Wikipedia edition (or on another wiki, such as Wikimedia MetaWiki) than the indicated article page on English Wikipedia (and possibly in its project namespace locally named ""wikipedia:") describing ISO 639 macrolanguages.

It is assumed that the hyperlink will be resolved from Wikimedia Incubator, where "wikipedia:" is an interwiki prefix; it then points to the English Wikipedia by default, so if we wantto point somewhere else, we need to use the syntax:

wikipedia:(target interwiki code known by English Wikipedia):(optional target interwiki language code):(Translated namespace name):(Translated article name)

So the prefix wikipedia: seems to be invariant in that case.

But Incubator can also resolve itself locally the (target interwiki code known by English Wikipedia): just like the English Wikipedia, so we don't necessarily have to use the wikipedia: prefix (which would work as well if it was written as w:. If we wanted to point to a page on Wikimedia MetaWiki, we could replace wikipedia: by mw: and would not use any (optional target interwiki language code):, but we would certainly have to follow it by a namespace on MetaWiki, and the target page name (whose title would remain in English on MetaWiki) would likely be followed by a /(target translation language code), and possibly by an #(anchor-id)...

For this reason, the target of the link should not be hardcoded, but replaced by a placeholder for a translation variable, as in [[$1|some translatable text]]. The module generating this message would insert its value coming from another separately tunable translation unit containing only a suitable full page name with the necessary interwiki prefixes (wikipedia: is just suggested in the source translation unit in English, but could as well evolve later if there's a more appropriate article than the generic English Wikipedia article describing ISO 639 macrolanguage, notably if there are recommandations for their use as interwiki codes, which actualyl are NOT following ISO 639 exactly but BCP 47, except for a few legacy codes specific to Wikimedia interwikis like "nrm", "simple", "roa-tara", "roa-rup", "map-bms" that must be explained somewhere else...) for targetting any other wiki (and possibly a language subpage code if the page name itself remains untranslated because it is generated by translating a source English page).


Note finally that the 1st hyperlink in that message (given just at start of my message here) assumes a format "$1 language" for the page title describing a given language (but we have to guess how this language is named in English, and there may be additional disambiguation suffixes such as a country name, because different unrelated languages may have the same name in English! as well that prefered name could change, because these names are not unique or there's a strong reason to use another one, because it caused confusion or there were political decisions, or some other consensus).

As well, the ISO 639 standard is not "stable" over time (unlike BCP 47): codes are frequently added, removed (possibly splitted if it was too ambiguous, or just obsoleted because it was added by error in the past, or just merged into another because they are now considered as dialects of another major language with which are mutually intelligible). The classification of languages into macrolanguages evolves too. Only BCP 47 offers stability of these codes which allows them to continue to be resolvable as much as possible (without even being affected by changes of their prefered names or classification), that ISO 639 has never been able to warranty over time. And BCP 47 has an exceelent repository for that, the IANA database of language subtags (there are some additional complexities that are solved by I18n libraries like ICU, possibly taking into account some additional subtags after the primary language subtag, and possibly altering how language fallbacks are resolved).

Also various languages don't have their own article: there are frequent cases where multiple related languages (in a closed group) are described in the same page. To solve that problem, the English Wikipedia offers an alternative title "ISO 639:$1" which will redirect to the appropriate place !

Verdy p (talk)02:11, 30 September 2022
 
 
 

OpenHistoricalMap (OHM) translations needing a review

Edited by 2 users.
Last edit: 13:50, 6 September 2022

I've sorted these OHM messages out on the command line. Their translations copied from OSM need !!FUZZY!!fication, because the source messages differ.

This should probably be bot work. (Western Frisian (fy) and Dutch (nl) can be skipped in that case.)

Kind regards

PiefPafPier (talk)09:26, 5 September 2022
Edited by author.
Last edit: 13:59, 6 September 2022

Note that this does not necessarily affect all languages: if they were copied verbatim by some bot (from resources translated for OSM), they need updates to match with OHM, which is still hosted by the OSM Foundation, but operated under different rules (and with a new OHM Foundation which will regulate it but which is still informal), and uses separate licences, separate user registration and contributor terms.

As well there are things to develop to better track the various licences used in the data (because there's no more any single licence, each object tracks its own licence, and it will not be easy to work with it with existing OSM editors (and data import tools, or QA tools): we don't even have an easy way to modify data if users operate under different licences, so a licence filter will be needed everywhere, notably in editors, and in data extraction and export tools). Because of that, new contributors may not easily track what is allowed or not, and working with different licences and timeframes will be very impractical, either damaging the geometries needed for other timeframes, or not allowing to close them corerctly with a complete geoetry, if subobjects needed are using an compatible set of licences (that existing editors and tools do not currently allow to check: merging nodes at the same or similar position for example will remain a problem).

For example, I carefully took that into account in French by not confusing the two projects.

Anyway the OHM project is still starting and still not really in production: there are lot of works to adapt it, including updating client tools, and probably define new attributes and methodologies to work with historical data and allow the map renderers to take that info into account (e.g. to "play" changes over a period of time), and some of these are unstable and need to be fixed: the OHM project will update these messages when necessary, so they will be marked "fuzzy" when they'll do. I think it is more like an alpha stage, just existing for now to demonstrate its feasibility. It's still not tuned for large-scale production and users will need to be trained to work correctly with the new rules (notably with licences).

Major issues when objects are linked together (e.g. ways defined in a given licence, but reusing shared nodes created with another; same thing relations, including for geometric areas using sets of ways that may not use all the same licences). It will also not be easy to track the validity in time. Editors will need to be smart to allow selecting or not some node that was defined for a specific date or period (in addition to the problem caused by the multiplicity of licences).

Things would be easier if instead of that, the legacy OSM data was using the general concept of "data layers" that would group objects belonging to the same timeframe, and the same (or compatible) licences, just like what is done in other GIS systems. But for now that extension does not exist and the existing "OSM v0.6" schema seems to be insufficient: it will need extensions to make those data easily reusable and editable, exportable and reusable. Lots of technical things will have to be discussed, and tested. So that project will necessarily deeply evolve with its own needs (but may be some of its extensions may become usable as well in OSM).

So I still consider OHM to be in alpha stage, a trial for demonstration and exhibiting the problems on limited areas for tests, before it can be used more globally. For now, other GIS solutions are preferable, just because they work on distinguishable layers of data and don't need to merge anything with unrelated datasets managed separately with their own policies.

And may be all OHM contributions should be made in layers, and merging layers (for reusing data, or faster rendering) should be performed selectively on the client side, not in the OHM database itself (in that case, nothing will prohibit OHM clients to use the OSM database just as one of the layers). But if OHM develops a new extended model, it could be useful as well for OSM itself (even if it focuses on just rendering the most recent data, but still does not accept planned data related to the future, such as construction areas) and could simplify the work on OSM for import bots (the actual merging could be made by OSM-trusted bots, after checking dates and compatiblity of licences), and the work in cooperating teams (each contributor would have his own layer, merged in the main layer only by linking to layered data), including for newcomers (who could also "try" their own layers, giving their owrk to other trusted users to fix it before it can be merged)

All this has nothing to do with translation. This technical work should be worked and discussed with OSM and OHM, and see later if these two projects can merge their efforts with a shared (layered) database using a new data model (but still offering an API compatible with v0.6 to give access to the "merged" layer (containing only data compatible with ODbL and with the correct current timeframe), which would no longer be directly editable directly but infered/generated by processing). It would also greatly facilitate the fight against abuses in OSM (copyvios, destruction/randomization, spammed contents) or unobvious errors made by contributors themselves (which are hard and costly to locate and fix after submission, even if they made their best efforts).


Note: I transformed your long list of messages first into a vertical list, but then into a bulleted list, showing links to messages: the links go to the translated versions, according to the current user's language, or the language you specify by looking at this page with "?uselang=code" added to the URL of the current page).

That list does not test if these translated message exist (because we are limited to 100 "#ifexist:" tests on this wiki) so these links may go to a wiki editor if these translations do not exist; it also does not show their textual content.

This makes the list more compact in the support page.

Verdy p (talk)09:47, 5 September 2022

Thanks for all the information! I would love to draw our heroic period in history 'Magna Frisia' on the map. We even learned the English to talk proper English in those days. Note to self: look up if that is true ;-)

PiefPafPier (talk)10:09, 5 September 2022
 

Could anyone please investigate the mess that was made by FuzzyBot today? See for instance fy, nl and maybe more. Thank you.

PiefPafPier (talk)19:35, 26 September 2022
 

Standardized message for "Translation administrator"

I was surprised to discover that there is no standardized message for "Translation administrator" in the Translate extension.

For Wikimedia, there's Group-translationadmin-member in Wikimedia Messages. For translatewiki, there's Group-transadmin-member, which is not assigned to any group.

Such a role is probably needed on every site with this extension. Shouldn't it be a part of the extension?

Amir E. Aharoni (talk)07:32, 26 September 2022

I think you are speaking here about the message for an individual user member of the group. That "*-member" message is normally NOT capitalized and singular: "translation administrator", unlike the name of groups (which is also the names of description pages or categories on the target wiki, which are translated according to the default language of the wiki and not the user-selected UI language).

That's why there are different messages even if they are closely related. Note also that for some languages, some wikis chose to use "neutral" ("épicène" in French) notation showing mixed a masculine+feminine form as much as possible, notably for messages showing a plural form, but sometimes as well for the explicit "neutral" gender (used by default for users that don't want to specify it in their preferences, or that have not set it, and generally selected for bot accounts).

This "neutral" form is sometimes the subject of debates, e.g. in French, because some users don't like the "épicène" orthography and still prefer seeing a "traditional" form (where the masculine gender "wins" over the feminine when there are mixed genders): they don't like seeing "administra·teur·trice" for example, but they accept the "(e)" or "(s)" suffixes to mark an optional feminine or plural... where it can apply. For longer messages, we sometimes prefer "administrateur ou administratrice" without using such "épicène" notation.

For such case, and to close some debates, may be we'd need variants in French for "trad" and "reformed", like they exist in German, Dutch or Spanish for "formal" and "informal". However such variants are still not registered in BCP47, which just lists variants for the orthographic variants (with a string community preference to keep the "traditional" orthography before the debated 1990 reform. For now French in MediaWiki doesn't use any variant. because the traditional ortography is STILL valid after that reform and can be accepted by everyone. In my opinion the "épycène" variant should not be the default (as it requires the addition of an unusual "middle point" punctuation that is not present on most French keyboards, and that notation confuses most text search engines and spell checkers; as well that "épycène" notation currently has no supporting standard, it is too recent in the history of the language but most frequently appears now in pages related to LGBTQ+ rights or feminism, that are politically/socially oriented and sometimes their usage cause new "hot" debates and bad online behaviors).

Like you, I strongly support closing the "gender gap" in wikis and open projects in general, i.e. including with more women.

(notably to show to males that women are accepted and have a voice to be heard including for decision processes, or page design, color choices, skins: let's stop the universal blue/gray used everywhere, we can all live even if there's some pink/purple or more colors, or some floral decorations... as long as we preserve or improve accessibility for color-impaired users with appropriate skins or features available to them; as well we must preserve the compatiblity for blind readers, users that prefer dark backgrounds, to save energy on their mobile device, and "redshifted" colors with reduced contrast when looking at pages in dark environments, to reduce the physical stress on eye).

But not at the price of inventing a new "neutral" gender (which does not event exists legally for now and that has compeltely disappeared from French since many centuries): as much as possible, we should use traditional forms with "or" conjunctions, except in very few messages that need to remain very short (but where the new "épicène" notation should be avoided by default, especially for plurals including with mixed genders). So solving the "gender gap" should only occur in translatable messages for referencing a single user (with the "GENDER:" parser function and a given local user name, but avoiding the "épicène" notation for the "unknown/unspecified/prefer not to say/non human/bot" case); however there's no restriction to do or enforce for content pages that will use the appropriate form for their discussed topic (and that should not need to use the UI language preferences of the currently reading user).

Verdy p (talk)07:49, 26 September 2022
 

Admin edit of MediaWiki:Feedback-termsofuse/pt

Could an administrator please change MediaWiki:Feedback-termsofuse/pt to:

Concordo em fornecer comentários de acordo com as condições de utilização.

Editing of the message is not allowed due to "You do not have permission to edit this page because it contains raw HTML which can be modified to affect all visitors."

Hamilton Abreu (talk)19:41, 24 September 2022

Done Done

Raymond18:59, 25 September 2022

Thanks, Raymond.

Hamilton Abreu (talk)19:29, 25 September 2022
 
 

Adding a new language, ISO 639-3: ldn (Request)

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


Álo (talk)06:11, 27 February 2022
Edited by author.
Last edit: 14:16, 27 February 2022

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.

Verdy p (talk)06:39, 27 February 2022

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.

Álo (talk)09:05, 27 February 2022

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)

Verdy p (talk)14:13, 27 February 2022
Edited by 2 users.
Last edit: 06:50, 25 September 2022

phabricator ticket for the WD side of things: phab:T302705

update: patch has been submitted

update2: patch was edited to exclude ldn before being merged, but the topic is now in discussion at d:wikidata:report a technical problem#Adding a new language code, ISO 639-3: ldn (followup).

Álo (talk)01:03, 7 June 2022
 
 
 
 
Screenshot from the gadget

Hello all!

About a year ago, I started developing the Terminology gadget, which is a tool to help translators keep terminology consistent for their language.

Now I would like to request that it is enabled as a default gadget, i.e. that it is turned on for everyone automatically. Since it is a gadget, anyone who doesn't like it can of course disable it via their preferences.

Any comments/objections?

Jon Harald Søby (talk)12:58, 23 September 2022

Its quit good for me and looks to me a component of the Translate extension.

Cigaryno (talk)16:32, 23 September 2022

Yes as long as it can be disabled (as least as long as we don't refresh the page, or in preferences for experienced translators that don't need it all the time but can feed the terminology separetely using another window or tab).

  • It may cause input troubles in some cases, or could provide unrelated hints when there are lexical ambiguities, without the possibility to make an appropriate choice with the suggestion(s) given, or the termiloogy data itself may be defective, needing additions or fixes.
  • The terminology (even if it is correct) may also contain extra terms to contextually remove (to avoid repetitions in the translated text).
  • In some cases, a repeated term may also be contextually replaced by a locally-unambiguous pronoun, or rewritten in another form (active vs. passive, noun vs. verb or participle) that is easier to read, making also long sentences easier to understand while preserving the intended meaning.
  • Finally the terminology list will always be defective for grammatical derivation of terms (plural/gender/case forms, conjugated verbs), and required contextual transforms (such as mutations/agglutination/elisions, as well as capitalisation): it should just offer hints, not requirements.

Also it does not seem that the data provided in the terminology lists is used to feed the normal search engine: I've never seen search results returning terms from these lists, only those from normal wiki pages and translation units. As well the terminology gadget still does not propose results from the local search engine (when showing hints, or when adding terms to terminology lists).

The terminology gadget also does not allow separating the proposed terms with some free text disambiguating its context of use: it tries term-for-term lexical correspondances, not lemma-for-lemma.

It may also start looking up for lexical entries or for labels of elements from Wikidata (possibly correlating them with sitelinks in Wiktionnary or Wikipedia for relevant languages). But this could also be integrated in the local search engine if the gadget can properly use the local search engine already configured to make these extra searches.

So finally, the gadget would remain quite simplist. More efforts should be made in the search engine, showing more contextual hints on the right pane, below the message doc. This right pane is also the place where, later, Abstract Wikipedia (also working with Wikifunctions and Wikidata, and possibly other open data sources) could also provide their own hints (in addition to existing translation tools).

In fact I did not find that gadget very useful and productive for now, I have however massively used the local search engine (to perform checks of coherence when there were multiple choices, or to find possible related discussions), and search engines of Wikimedia wikis and of development project sites (outside MediaWiki itself).

It should also be noted that projects not directly related to MediaWiki use their own terminologies with distinctive terms. The gadget currently does makes any difference, depending on the project we are translating for within the Translate UI. Once again this is the problem that it shows no context to allow proper choices: translating something without taking into account the context of use is full of traps! That's why the right pane, showing the doc for each translation unit and other relevant infos, is still the best place).

So for me this gadget is just a transition tool just here to fill a gap for "fast startup": for languages that are already very advanced, it is already not needed at all. And in my opinion it is more a pollution than a real help when working on translation reviews. It may just help early translators, but not reviewers (we need more reviewers, but to capture them we need more efficient search tools to help them: so please continue working on the right pane of the translate UI, which will not just help Translatewiki.net itself, but also all other translation tools for wikis in Wikimedia or elsewhere, using the Translate UI or extensions based on it!).

Verdy p (talk)17:29, 23 September 2022
 

I forgot I had to enable this and thought this was already a default feature. I support making it default, it is useful

Bgo eiu (talk)23:19, 23 September 2022
 

If this "nd" string is a suffix for English only, it should not be translatable. The result of converting a number to an ordinal (like "2nd") with a suffix is not directly translable in most languages as an appended suffix.

Please check the possibly incorrect assumptions here and fix it: either remove that translation unit if this is English only (but then be awere that this test will not perform anything useful for other languages that won't be tested at all).

Or provide correct format for translated ordinals (and don't make assumptions about numeric ranges for each ordinal abbreviated format:

the rules or English do not apply to any other languages, which use other sets of affixes with different sets of values; e.g. "1st" and "21st" in English both use the "st" suffix depending only on the last digit; but in French, "1er" or "1re" is used, depending also on the grammatical gender like also in Spanish; French uses the same suffix "e" for all other ordinals like "2e", "3e", "4e", "21e", independantly of the last digit; other language do not use such notation but may use prefixes like "#" or a prefixed word). And the set of numeric values for which each ordinal affix applies is also language dependant, as well as the grammatical form of the affix (which may depend on grammatical case, plural, or gender, and may also change the placement relative to the number with which it attaches). So "nd" cannot be translated alone, we can only translate "2nd" and only in context of the sentence where it would be used (using "PLURAL:" for specific numeric values, because there's still no other way to replace "PLURAL:" by "ORDINAL:" to classify ordinal numbers, in a way which is different from usual plural rules, and then select the appropriate textual form of the ordinal).

If this is for something else, please better explain the intended meaning.

For now there's no way to determine what to do in translations, or if this test will effectively succeed.

Verdy p (talk)06:07, 23 April 2022
Edited by author.
Last edit: 17:33, 20 September 2022

just [ping], as there's not ben any reply since 4 months and we still don't know what "nd" alone means and how it can be translated. Normally Arcanist is part of the Phabricator extensions supported by Wikimedia. But may be it has not been officially retired or does not use this specific message due to some disabled feature? I don't know who to contact if this is supported upstream, or if this is an old legacy message no longer used.

Several message seems also to be related:

  • arcanist-core-9b02d9974c14e623 ("!!FUZZY!!er") (it is an ordinal suffix hardcoded for using rules valid only in English: "1st", "21nd", ... "91nd", but not "11th"; note also that in French, Spanish, Portuguese, Italian, this ordinal suffix will vary according to grammatical gender, such as "er" vs "re" in French, or "º" vs "ª" in Spanish/Portuguese/Italian...)
  • arcanist-core-3119f17b3b50c21d ("nd") (same indicated PHP source file, just one line below, it is an ordinal suffix hardcoded for using rules valid only in English: "2nd", "22nd", ... "99nd", but not "12th"; this does not vary in French but varies in Spanish/Portuguese/Italian...)
  • arcanist-core-9f6194d012e32351 ("rd") (same indicated PHP source file, just one line below, it is an ordinal suffix hardcoded for using rules valid only in English: "3rd", "22nd", ... "99nd", but not "13th"; this does not vary in French but varies in Spanish/Portuguese/Italian...)
  • arcanist-core-fa6af6e97d010a98 ("th") (same indicated PHP source file, just another line below, so it is likely an ordinal suffix hardcoded for using rules valid only in English: other cases; this does not vary ni French but varies in Spanish/Portuguese/Italian...)

Such messages are perfect example of "pachwork" messages that are NOT correctly internationalisable (using abbreviation suffixes out of any context, and hardcoding the linguistic rules always like those applicable only to English), whereas CLDR or similar functions would better help.

If you really want to support suffixes after numerals for expressing ordinals, these suffixes should be styled in superscript tags (even if it's not needed in English, and should not be done in German, where the suffix will be a ".").

For this reason, Phabricator should use a good converter from numbers to ordinals that can take these into consideration: there alerady exists good i18n templates/modules already for that in Commons, with relevant data for many languages, including the special formaters for centuries or millenia.

Verdy p (talk)16:46, 2 August 2022

For some reason, the translation appears 'outdated' while nd is the only possible translation.

Cigaryno (talk)17:44, 24 August 2022

I don't agree; there are other solutions if these two messages are intended to generate ordinal suffixes: don't hardcode ordinals this way; but this requires patching the source code.

  • If we translate to French for example we could use the alternate suffix "e" for all values... except for the 1st ordinal which should be suffixed by "er", but the current hardcoded rules for English don't work this way (e.g. "1st", "11th", "21st" in English, versus "1er", "11e" and "21e" in French)
  • In German this would be simpler as a general suffix "." can be used for all ordinals
  • Some language require varying the suffix (e.g. by grammatical gender or plural or grammatical case according to the nominal group that the ordinal qualifies)
  • Other languages would use a prefix instead, such as "nº 1".

Using these messages as is makes no sense at all except in English. CLDR has resources about ordinal formatting (but only for the nominal or vocative grammatical case). But in fact It would be simpler to adapt messages if ordinals were not made translatable using this patchwork model, but using complete sentences containing the ordinal (and just a placeholder for the numeric value): we could then use "PLURAL:" parser function if needed, or use alternatives like "nº 1" that do not depend on the numeric value, or translate without any ordinal.

Translating suffixes only, without using a placeholder for the numeral value, makes NO sense. These 4 messages (currently hardcoded and tuned for following rules only valid in English) must be replaced by "$1st", "$1nd", "$1rd", "$1th" (or just by a single message using for example "#$1" or "nº $1" without needing any ordinal form) so that we can create correct translations.

  • Only German-like translations (also used in some Central European languages) can use a "." suffix for the ordinal indicator to be used in all 4 messages (which can then all be turned to "$1." when using the "$1" placeholder).
  • But that solution is NOT permitted for Romance languages which allow a final dot as an abbreviation mark only when the word is abbreviated using only its first *letters*; but when there are no letters, just digits, we MUST use final letters of the ordinal suffix, and they vary in gender, possibly even in grammatical case for some languages (so the alternative is to not used suffixed ordinals, but expressions with a common prefix like "numero $1", abbreviated as "nº $1".
  • Various languages do not support any suffixed notation for ordinals, but only prefixed notations.

After searching the code, I found that these ordinals are used for testing the translated formatting of dates, only for days of the month. This is not clear in the current doc. And I don't know if this code also tests for other locales than English.

But then these ordinals are not necessarily using ordinals suffixes in formatted dates (for example in French, only "1" is suffixed as "1er", whereas all other days of the month do not use any suffix. Note also that the ordinal suffix "er" is superscripted, but I do not know if the formatted dates can include HTML formatting, so the test could as well accept "1er" (e.g. when processing dates with a plain-text command line interface.

Other solutions could also use specific superscript characters (normally encoded in Unicode only as "modifier letters" for compatibility with other notations such as phonetic notations or common abbreviations used in Spanish/Italian/Portuguese, in a restricted set of letters: this subset includes 'ª' and 'º' as symbols for compatibility with ISO 8859-1, but not the superscript 'e' and 'r'; it contains a superscript 'r' as 'ʳ' (U+02B3) only as a modifier letter for IPA, but no superscript letter 'e' that would be needed for French dates, and no other superscript letters used in French and other languages for noting the final letters of many abbreviations. So these "compatiblity superscript" or "letter modifiers" are not usable (they are also incompatible with transforms of letter cases): we need rich text with styling (i.e. <sup></sup> elements in HTML) for normal processing (note that these are not really "styles", because they are semantically significant, offering distinction in some cases, but not here within dates, so we can still recognize the date "1er octobre 2022" even if it should be "1er octobre 2022" with the normally required superscripts).

Note as well that English also uses sometimes superscripts for abbreviations when they are semantically significant. But Unicode/ISO/IEC 10646 contains no formatting control that could be used to alter the semantics and rendering of a normal letter to make it superscript (some font formats like OpenType and text renderers have such capability which contextually transforms some letters to superscript if they occur after a decimal number, but this does not work if this occurs with Roman numbers, like "XXe siècle" in French so you'd still see "XXe siècle"...

If these 4 messages are just intended to test the date formater in the English locale only, these 4 messages should not even be marked for translation (so the PHP source code is incorrect and should have not used pht("st") for example to mark these as translatable.

See:

Verdy p (talk)04:38, 25 August 2022
 
 
 

Adding Phorge for translation?

Some users may known Phorge, a community maintained fork of Phabricator. I think translatewiki.net should enable it as seen here.

Cigaryno (talk)19:48, 12 September 2022

I know that, and in fact several translation bug reports that were sent to Phabricator were rejected (since they come the earlier version inherited from Facebook (when it abandonned that project) and sent "upstream" (because they were not used by Wikimedia) but without a real upstream maintainer. Phorge has taken the hand on these unused modules, creating its own fork (more or less synchronized with Wikimedia Phabricator for some modules but not completely, so there are now differences).

I think that both Wikimedia and Phorge should cooperate to have a set of common modules maintained in a "Core Phabricator" part, even if there are Wikimedia Phabricator-specific modules and Phorge-specific modules: splitting PHabricator in three spearate groups would help and would void duplicate efforts from both Wikimedia and Phorge, and there should be a joint working group to see how they will reconverge their versions on the common modules that will be part of "Core Phabricator ".

Today Phabricator is very large, and difficult and long to translate, even if there has been efforts to modularize it (just like there were efforts for MediaWiki extensions, and joint working teams for other large wiki providers like Miraheze, or even Fandom, the new name of Wikia that is no longer supported here, but Fandom now operates with its own proprietary licences and does not want to cooperate; may be they should revize their decision, because I doubt they will even be able to track all issues alone, and their operational costs will increase and even their hosted communities have difficulties to work with their official support, that is very slow to react and solve problems, or cannot supprot as many languages than those supported in standard MediaWiki).

Creating joint efforts has a price: the main one is related to licencing issues, but modularizing projects would allow better convergence on the most core components that should be maintained in a single open project, without duplicating most efforts (notably for translations to "minority" languages: joining efforst would allow better reviewing with more contributors, not necessarily tech-savvy, so it would also improve the overall quality for everyone).

Consider how ICU evolved: from a project maintained by IBM alone, now maintained in a more open project at Unicode, it starts being more useful and now largely used in other I18n projects, but it is still slow and there are still considerable optimizations to implement so that its submission and vetting process works more reliably on smaller devices, but as well to have the serverside components work faster. This means going to "continuous integration" (at least in a "development branch", even if there are yearly major upgrades with stabilized branches and some backports). Due to the growing cost of maintenance of ICU, now Unicode has placed all its maintained code in Git (where multiple branches are possible and integrable. This should finally work like other large projects (like Linux kernels or LTS distributions running along with rolling releases)

Verdy p (talk)06:43, 13 September 2022
 

Translations that I cannot change myself

Hello, can someone please update these locked translations? (NB: the < and > symbols are ampersand lt and ampersand gt, but they are displayed here as < and > even inside nowiki tags)

Huñvreüs (talk)16:33, 10 September 2022

Done. Please check.

Amir E. Aharoni (talk)07:24, 12 September 2022

Looks good, thanks!

Huñvreüs (talk)21:02, 12 September 2022
 
 

Portal:Acm

Hi This language is disabled, I hope to restore it so that we can work on it --Ahmedadeljaff (talk)

Ahmedadeljaff (talk)17:13, 2 September 2022

Enabled.

Amir E. Aharoni (talk)07:31, 12 September 2022
 

GENDER purposes

Is it really needed to use "you" and "your" along with the GENDER parameter in most MediaWiki messages in English?

Vlad5250 (talk)13:34, 10 September 2022

Yes. There is a gender difference in the second person in Hebrew, Arabic, and many other languages. There is no such difference in English, but it hints to the user that GENDER may (and perhaps should) be used in the translation. If it's not needed at all in the language into which you are translating, just write it like in English, e.g. {{GENDER:$1|вас}}.

Amir E. Aharoni (talk)07:31, 12 September 2022
 

Please delete this page

I have been requesting the deletion of this page three times and nobody gives me a solution. I can't allow my old username to still be there in plain sight, please do something, edit it even if it's to delete that old username, because I changed my username but that page is still there...

https://translatewiki.net/w/i.php?title=Thread:User_talk:Iv%C3%A1ns/Por_favor,_non_sigas_cambiando_as_traduci%C3%B3ns_sen_consultar&lqt_oldid=81444

If it is not possible, edit to eliminate its indexing in google, since I want to delete its trace!!!

Iváns (talk)22:26, 4 September 2022

The thread is already edited. It is not possible to edit the history. Deleting the entire thread is the only option. I am an administrator and tried to delete the thread, but I'm getting: 'Internal error [fa9c1ee09e09167d53f2a2b7] 2022-09-08 11:40:21: Fatal exception of type "Exception"'

Nike, can you fix this?

McDutchie (talk)11:58, 8 September 2022

Its not possible since LQT is no longer maintained.

Cigaryno (talk)13:47, 8 September 2022
 

Reason?

Iváns (talk)20:18, 10 September 2022
 
Edited by 2 users.
Last edit: 12:28, 10 September 2022

If you don't want to have your existing talk page to be indexed by web crawlers (like Google), you need to edit your talk page header yourself by adding the __NOINDEX__ keyword to it. This will instruct web crawlers to NOT index this page, and (hopefully) remove it from their existing index.

I tried to do it for you, but it did not work: apparently MediaWiki only allows the User talk page owner to add that special keyword himself, otherwise it is not honored when saving (it does not alter the "page information" and so that keyword remains parsed as visible plain-text).

Try it: look at the rendered page (the keyword should be invisible and the "page information" should show that indexing is disabled. Then try looking in a few weeks at search engines to see if they effectively drop your user talk page from results from their search index, as instructed to them (give them time to revisit your talk page).

Note that individual "Thread:" pages managed by LiquidThread do not seem to automatically inherit that setting, so you may need to add the NOINDEX keyword in the top message of each thread you talked to, and that you don't want to be indexed by search engines. LiquidThread is not easy to manage, and in fact is now unmaintained. But this does not prohibit you to ask for deletions of thread pages and of your parent talk page, or "redacting" your edits top them in the page histories.


On some other Mediawikis, there are some authorized tools and Mediawiki extensions or privileged bots to automate it, where contents edited by others (and that must be kept) will be modified to "anonymize" your user name by using a randomly generated unique id instead, but I don't know if these tools work with LiquidThread pages, if they cannot "redact" the page histories.

But remember that when you started edited this wiki (or any other wiki), you accepted its open licence. So unless there are privacy issues strictly related to your personal data (just as your real name, email and street addresses, phone numbers and social network contacts) that is exclusively protected by law for you, all other contents your created or edited are available to anyone and that licence is irrevocable! So "redactions" will remain limited for legal reasons (related to the legal proof of ownership of the granted licence) all that can be done to the conserved content can only to be associated to an anomized unique identifier. Users should choose their public user names carefully if they are concerned by their privacy (this is not enough explained when creating an account on the wiki).

There are very few admins in this wiki (I'm not one of them, so I can just guide you and provide limited help or hints), and they don't have enough time to redact tons of pages (at least not without using some tools that they have been able to test) if many people ask for it, so be patient and consider your initial decision about usage terms and licencing that you accepted irrevocably.

Verdy p (talk)09:52, 9 September 2022
 

Saraiki language ?

Hello,

Today I noticed that in MantisBT we have an unhandled language file 'strings_skr-arab.txt'. According to ISO 639, this is Saraiki language.

Looking for it here, I found 2 entries for it

Screenshot 20210607-101200.png

Following the 2nd link gives an error message: Sorry, the servers are overloaded at the moment. Too many users are trying to view this resource. Please wait a while before you try to access this resource again.

-- Damien08:14, 7 June 2021

Thanks for reporting this. This happens when statistics for a language are initially not available, but are being calculated in the background and then cached. If you try to access the link again after a few minutes you should see the statistics.

I'll check with Niklas if we need to improve the reporting here

Regards,

Abijeet Patro (talk)13:00, 22 June 2021

Code map entry was added for skr-arab, so the request is fulfilled.

Nike (talk)13:44, 22 June 2021

I just got a mail notification about this page this morning, not sure what triggered it.

Anyway I just wanted to let you know that, over a year later, there are still 2 entries showing up for Saraiki when picking the language (as shown on the original screenshot). Not sure if this is an actual problem or not.

-- Damien08:40, 9 September 2022

Saraiki has multiple scripts, but for now only the Arabic script is supported (and it may/should be the default if there's no script specified, unless another script is enabled like for Chinese or Serbian with their two script variants, causing the code without the script specifier to become deprecated/disused for translations, while still allowing a single portal to present these variants).

User categories may or may not specify their script variant in their Babelbox, so there are different categories ("skr" containing "skr-arab" as a subcategory). We don't know if and when another script variant will be enabled for that language (this will depend on community demand and support).

Note also that Saraiki is itself a member of another macro-language, with its own code in ISO 639 and BCP 47 (see Portal:Lah : Lahnda, لاهندا), and also using Arabic as its default script for all its existing member languages (but some of them also have script variants), because this script is now the most frequently found script for the modern usage of these languages (but this does not mean that other scripts are no longer used, there may exist minorities still using those variants, or other scripts for expatriated minorities that now live in other countries where another script is dominant and taught in schools). That's not exceptional and exists in fact for many languages (including English, which also uses in some cases the Deseret, Braille and SingWriting scripts, in addition to the dominant Latin script).

Verdy p (talk)09:02, 9 September 2022
 
 
 
 

Registering an extension fork – partial message key collision

Edited by author.
Last edit: 18:29, 31 August 2022

Hi, in the coming days I will be applying to register mw:Extension:MediaUploader on Translatewiki. There's a catch, though – MediaUploader is a fork of mw:Extension:UploadWizard. I have renamed the vast majority of messages inherited from UploadWizard (and changed them as well), but there are still a few messages that have to keep their old keys for technical reasons. For example, I want to maintain backward compatibility with UploadWizard's user preferences and edit tags. Thus, MediaUploader has to use the same preference and tag keys, which in turn means that MediaWiki will force me to use the same message keys as UploadWizard. This is not a problem for users, because the two extensions cannot be installed side-by-side, but if I understand correctly the mechanisms of Translatewiki, it will be a problem here.

Is there any way around this issue?

Ostrzyciel (talk)18:29, 31 August 2022

Hi, any updates on this? I have been thinking about this myself a bit, and the only solution I can think of would be to prefix the colliding messages on translatewiki.net, but not in the extension. So, for example, UploadWizard would keep its tag-uploadwizard message here, but MediaUploader would be assigned mediauploader-tag-uploadwizard, which would be mapped to tag-uploadwizard during translatewiki.net -> code repository migration.

I have no idea if this is possible or not.

Ostrzyciel (talk)16:13, 4 September 2022

Hi, sorry for the late reply. You can prefix message with "prefix = mediaupload-" in https://gerrit.wikimedia.org/r/plugins/gitiles/translatewiki/+/refs/heads/master/groups/MediaWiki/mediawiki-extensions.txt, see exisiting lines there.

I would suggest to send a patch for register of the new extension with the prefix lines for the message keys with collision.

I will review the patch.

Raymond07:40, 5 September 2022

Ah, that would solve it, thank you! I will submit a request to register the extension soon.

Ostrzyciel (talk)13:25, 6 September 2022
 
 
 

Change Username

Can you change my username to "बडा काजी".

Bada Kaji (talk)21:05, 2 September 2022

Done.

Amir E. Aharoni (talk)09:53, 3 September 2022
 

Is there a process to pause the call for translations ?

Edited by author.
Last edit: 19:24, 2 September 2022

Hello, I'm the lead developer and editor for Translating:Lingua_Libre_SignIt. I've been very impressed to get 19 20 21 22 full (100%) translations and 16 partial ones within a single month. Impressive.

I would like to pause the translations for now, however.

As of now, Sign It is a translation web extension, translating from French written words to French sign language videos. Media resources are only available for French Sign Language. Target users are French speakers.

While I plan ahead for future expansion to other 6~10 major written languages and sign languages videos pairs such as English + American Sign Language, Italian to Lingua dei segni italiana and few others, these resources are currently not available, and wont be on the next 2 to 5 years.

Without the relevant service to end-users at sight, I don't feel reasonable nor respectful to go toward 30, 40, 60 translations nor to ask translators of smaller linguistic communities for their translation service at the moment, since those minor languages translations have zero changes to be deployed and used.

Also, 'is there a way to "pause" or reduce the visibility of Translating:Lingua_Libre_SignIt in order to not attract volunteer translators for some times (years), but allow me to continue ocassional translations if necessary. Yug (talk) 19:41, 1 September 2022 (UTC)

Yug (talk)19:41, 1 September 2022

Well it is astonishing that this project attracts lots of interest, and it is very strange that such attempts was not even started before anywhere else (not even by large companies like Google or Apple). Evidently the needs are tremendous, and fully in line with the Wikimedia missions as it can seriously benefit to a lot of people.

Of course the complement will be to also develop a free good converter from text to voice (including with natural tones (this already exists in some OSes), but as well to Braille, without having to depend on large companies selling intrusive speaker assistants or vocal assistants for smartphones: people should be allowed to communicate usign free tools that will respect their privacy (including when they really want to have private, intimate conversations), without fearing some stress when using a third-party or governement-promoted service (even if this is delegated to an association with people behind; yes technology may help but it should be neutral and not traceable: we should be able to speak and debate about anything, without "banned" words, or "taboos", including for political/religious topics of interest), at all ages, and with the same level of trust that we may find with a doctor, psychiatre, or social worker.

As hearing impairments is also developping fast today, and people get older, we are all concerned. Thanks for that marvelous idea. Let's hope that other projects will seriously consider video solutions (which could greatly accelerate thigngs when all efforts to create a written transcription for sign language have essentially failed or stalled since too long. Signs languages are for everyone, and they are even easier to communicate with larger communities, as many signs are borrowed across cultures and share the same useful tips to extend themselves by practice. Sign languages are true languages.

Verdy p (talk)22:30, 1 September 2022
 

It's not such a big deal, as long as you document it clearly on the Translating:Lingua Libre SignIt page. If people want to translate despite the low usefulness, why not allow them.

That said, it is technically possible to limit the translation to some languages in the configuration, so if you really want it, just reply with a list.

Amir E. Aharoni (talk)12:14, 2 September 2022
 

Change Username

I want to change my username to Aishik Rehman. Hirok Raja (talk) 14:45, 1 September 2022 (UTC)

Hirok Raja (talk)14:45, 1 September 2022

Done.

Amir E. Aharoni (talk)14:56, 1 September 2022
 

OpenStreetMap.org Translation Fixes

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.
Firefishy (talk)01:07, 5 December 2021

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

Firefishy (talk)05:48, 15 December 2021
 

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,

Regards,

Abijeet Patro (talk)11:58, 16 December 2021

Hi,

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

Firefishy (talk)23:58, 6 June 2022

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.

Verdy p (talk)08:32, 7 June 2022
 

Closing this request... There is now an open ticket for fixing the outstanding en-GB issues: https://github.com/openstreetmap/openstreetmap-website/issues/3671

Firefishy (talk)21:59, 31 August 2022
 
 
 

Where is project ?

Edited by 2 users.
Last edit: 17:32, 31 August 2022

Hello there,

For Lingua Libre SignIt, I found the page Translating:Lingua Libre SignIt, and I see SignIt in Category:Supported projects. I now share this page to encourage wikimedians to translate this Firefox extension.

Another project I work on and which is translated by translatewiki is Lingua Libre Record Wizard.

I see it on github repository history.

I also see in Translating:MediaWiki/extensions_used_by_Wikimedia you do the translation for :

  • Record Wizard :
    • Record Wizard - User interface
    • Record Wizard - API


But for Lingua Libre Record Wizard, I find no such Translation:{Project name} page with description and overall stats. I would like, similarly, to encourage translation but I can't without an entry point.

Should I help create Translating:Record Wizard - User interface and Translating:Record Wizard - API ?

Yug (talk)17:40, 10 August 2022

I can create it, I thought it was just a generic extension for MEdiaWiki and it is also part of the messagegroup for ALL MediaWiki messages. I has not included as part of Lingua Libre too. Note that most Mediawiki extensions don't have their own "Translating:Page", there are really many (and ti takes time to create them, index them, find relevant identifiers for statistics)!

But nothing prohibit creating a specific page to show statistics for a specific one.

I would suggest however keeping only one page for the UI and its API grouped together. We can still display statistics for both individually, while giving a common description. For now, this was never asked for all the zillions extensions of Mediawiki, which just use the parent page "Translating:MediaWiki". Note that some MediaWiki not created nad managed by Wikimedia, such as Miraheze extensions and BlueSpice extensions, have their own "Translating:Miraheze" and "Translating:BlueSpice" parent page, listing all their subgroups, as they also have a supergroup grouping them all together (and they are not counted in the "MediaWiki (all)" supergroup.

Is there something specific in that extension for Lingua Libre? Or was it developed for specifically Lingua Libre as a component necessary to build the database to be used used by the Signit tool?

Verdy p (talk)17:45, 10 August 2022

Salut Verdy p ! ♥___♥
Several things there make Record Wizard an odd project !

  • It is technically a MediaWiki extension, but it requires a wikibase, Oauth connextion to Commons, which make it a one shot with no vocation to be deployed elsewhere.
  • It is planed (2023) to decouple it from MediaWiki, making it a standalone HTML/CSS/JS Single page app relying on Commons' Wikibase. MediaWiki extension part, out ! It will lighten maintenance and developemnt costs. The texts and translations would stay the same.
  • It works in the field of languages diversity, with language conservationists, activists, so we have higher and wider translations requirements. For those, I/We need a clear landing spot on TranslateWiki so I can redirect mitority speakers to it.

This being stated, we may be in a case where it worth splitting away from Translating:MediaWiki if translation rate stay similar.

Yug (talk)21:07, 10 August 2022

I will create the page just like I did for SignIt.

But the Record Wizard seems tobe usable for any other use in Commons, than just SignIt. Users could as well upload their audio or video records without necessarily feeding the SignIt database.

For example free casts to be used in Wikinews, or recorded lesssons for Wikiversity, or keynote presentations in Wikimania and other meetings, or free musical performances. It's basically just a wizard used to simplify the upload and check that everything is correctly indexed in Commons, and Wikidata. SignIt may need specific categories or data in Wikidata and some format restrictions (such as duration, and synchronization with timed text, and correct identification of the language, or a set of selectable languages for translated subtitles): using external tools is still possible, but they are not necessarily integrated enough with Wikimedia Commons and Wikidata, and many things are manual or lengthy for users, the wizard can automate these steps to avoid basic errors or "boring" syntaxes.

Anyway for now you just have a Mozilla extension. However most users don't have a Mozilla-based browser; most of them use now a Chromium-based browser (including Chrome, Edge, or Vivaldi) or extensions for Safari (MacOS and iPhones). Firefox is fading now, including on Linux even if it is still installed by default in many distribs (but no longer all of them, they already have difficulties to maintain these Mozzilla extensions which have serious security and stability problems). Are you working to port this SignIt extension to Chromium or Safari?

Verdy p (talk)00:00, 11 August 2022

Record Wizard current main application is to upload thousands clean audios (and few videos) words to Commons.

Then, three systems are used to spread an consume those medias :

  1. User:Lingua Libre Bot add those files to relevant Wiktionary pages (fr,oc,shy,ku and wikidata), so users can play them
  2. Downloadable datasets, for developers to create apps.
  3. Lingualibre:Apps, other apps using our medias

We have discussion about futher recordings features for longer texts but we lack human resources to lead those developments.

As for extensions diversification, the Firefox to Chrome adaptation is straight forward. Bu since SignIt is still in active development for i18n and other needed sugar, this diversification is "for later", when the code is truly stable. I haven't investigated Safari yet.

Yug (talk)07:17, 11 August 2022
 

Oh, I'm discovering there is a way to share a landing page for a given sub-project. Example : Record Wizard -> atj. It's just we have to know translatewiki's UI to search properly and find it. I understand better.

This being, and given translatewiki reasonable mindset to avoid project multiplication in order to keep maintenance edits low... It could be best to put both RecordWizard (150 messages) and the new SignIt (~30) under a Lingualibre umbrella. The human-friendly Translating:Lingua Libre SignIt could easily be changed into an umbrella Translating:Lingua Libre group. I could handle 3 sub-section pointing to bug trackers, referent users, link to project-specific translation. With such renaming you can keep the logo and a bunch of things (categorized users). Verdy, what do you think of this approach.

Yug (talk)08:21, 11 August 2022
 
 
 

For now, a separate translatewiki project is not really needed because these are pretty usual MediaWiki extensions, and there are hundreds of them. They are not even very large—Semantic MediaWiki, Visual Editor, Mobile Frontend, Growth Experiments, Wikibase, or Translate are much larger.

Maintaining a good extension page on mediawiki.org, like mw:Extension:RecordWizard would be a good idea, however.

Amir E. Aharoni (talk)16:21, 11 August 2022
 
First page
First page
Previous page
Previous page
Last page
Last page