User talk:Jack who built the house/LiquidThreads

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

translatewiki.net

Introduction

Getting started

• Translation tutorial
• How to start

See also

• Localisation guidelines
• Translating offline
• FAQ
• Support

Hi Jack who built the house. Welcome to translatewiki.net!

You can now start translating.

You should also check the portal for your language, the link is in the sidebar. Other useful pages are linked in the menu next to this message.

Your translations are transferred to the standard product every few days or every few weeks, depending on the product. Please notice that it may take longer before you see your translation in the actual product.

We wish you a productive and pleasant stay. Please leave any questions on Support (the link is also available on any page, in the navigation sidebar). Cheers!

-- WelcomeMessageBot (talk) 11:49, 13 March 2016 (UTC)

Your recent dummy change that uses {{PLURAL:$2|1=some form|some form}} in English messages is incorrect: plural rules cannot have a distinctive value selector (including "1=" here) that maps to the same form as the default rule (in last position without selector).

In all cases we get validation warnings asking us to drop this dummy selector when translating:

• Wikimedia:Convenient-discussions-thread-expand-label-genderless/en
• Wikimedia:Convenient-discussions-thread-expand-label/en
• Wikimedia:Convenient-discussions-thread-newcomments/en

If you need to include a dummy reference to $2 (containing the actual raw numeric value) so that it may be used in translations to languages needing it, just insert {{{{PLURAL:$2|}} with a single default rule (you don't need to place a non-empty text in it), and then document in the "/qqq" message that you support the "1=" selector if needed (for a very specific singular).

As well the kind of numeric selector used ("1=" )is assuming that its mapped form will be used for singular (e.g. to translate the displayed value as "one", and that the default form should then be plural and used for all other numeric values (including 0) that will be rendered with their localized numeral form (with digits): This is WRONG (e.g. in French, where singular also includes 0 or any absolute value lower than 2).

Do not use an explicit "1" selector, just use the default selector for singular, so that it will correctly distinguish the singular (given in the first form) from other plural(s). See CLDR data for how languages map singular forms (and optionally have plural forms: languages withotu singluar/plural distinction just use a single default form and will not specify a separate one). In such case the first form will be used for all singular values (so they cannot be translated as "one" or "1", we have to include "$1" to show the actual value, which may be "1", but may also be "0", "0.5", "1", "1.2" in French).

Note that for now there's no support in Translatewiki.net to distinguish the "zero" value, even if it is extremely common in languages, that prefer using negation (with adjectives like "no", or pronouns "none", "nothing", or adverbs like "not") instead of using either a spelled "zero" adjective, or a numeric "0" using digits (good for tabular data, unless we want to display an empty cell or a cell with alternate presentation like a centered/grayed "N/A" or "—"): to support these prefered form for "zero", the application should beter make a distintive message used with a specific test of the value. And once again do not assume that "zero" is plural like in English (in fact this is wrong as well in English when using some negation forms: it is plural only with "no", "zero" or "0" adjectives, but singular with the "not" or "never" adverbs and with the "none", "nothing" or "no one" pronouns... English is incoherent here! One more good reason to separate translations for the "zero" case by using separate translation unit).

@Verdy p: Hi, thanks for the overview. The problem I was trying to address with this change is that people are generally unaware of the existence of 1= rule (as I was myself). This resulted in wrong translations to quite a few languages. So this is what I'm trying to solve here.

I'm afraid a lot of people don't read the documentation. A placeholder might actually nudge them in the right direction.

> we get validation warnings asking us to drop this dummy selector when translating
Where do you get such warnings? I don't see them. I saw these warnings where there was no 1=. Yes, to use 1= to suppress the warning (and get correct translations at the same time, because without 1= they can be incorrect) is hacky. But in the absence of a better solution could this be a less of two evils?

The places where I used 1= in placeholders allow only non-zero natural numbers. So, there shouldn't be a problem with French.

In fact, there shouldn't be a problem with French in any case, if I read you correctly. Because the places where I used 1= don't have numbers in the output. That's the whole point. For example: {{plural:$1|There is a new message|There are new messages}}. 0 shouldn't matter here.

Another problem comes from the fact that when using "numbered parameters" (actually a plural selector), the follownig "unnumbered parameters" are also given implicit keys, so there is a collision; this should normally not affect effective "parser functions" of Mediawiki, but this causes a confusion depending on the way these messages are parsed. The MediaWiki parser does not process parser function calls exactly the same way as template transclusions (where these collisions are ocuring because all template parameters must be given a unique "name" used as keys in the same table of parameters, whereas parser function calls treat all parameters in a table keyed only by integers and whose entries are (paramname=value) pairs, so that all parameters can be processed in the expected order and can even specify the same "paramname" multiple times (we can't assume that in templates).

So parserfunctions calls like {{Plural:...}} work differently than transclusions like{{Plural|...}} (and this complicates things in MediaWiki because transclusions may give a page name for the template which may also have a namespace prefix: the distinction is not made by the syntax, but by first parsing MediaWiki like with parserfunction calls, then remap the integer-indexed array of (key=values) pairs into a table keyed by parameters (voiding their order) only when this syntax des not map to a parser function call but to a template transclusion.

Anyway this is a case where we are in borderline of very tricky cases, that translators should not have to care. Specifying plurals rules (or gender, and other 'tagged grammar") in translations is something that is still not cleanly solved in translatewiki.net and translators have difficulties to figure out if this works and how: even for MediaWiki alone there are several syntaxes used (depending on whever the MediaWiki parser will process the message or not, or if it will be processed by some other i18n library or directly in PHP; as well this complicates imports/exports and compatiblity with other formats (notably .po for Gettext, which is the least permissive).

Ideally we should support plural cases using CLDR rules only (using symbolic selectors like "one", "two", "few", "many"), and specific cases with numeric selectors should never be used in translation units. But we have to live with the legacy implementations and with the "strange" Mediawiki parsing rules. But even the CLDR rules have also evolved over time (see the specifications of LDML, now hosted by the Unicode Consortium and no longer depending on the legacy IBM version of ICU...). Finally there's an interesting evolution used in FreeCol, which allows a more generic and unified solution for supporting arbitrary number of linguistic features (not just plural, gender or grammatical case, it can also support lexical types and semantic classifiers) using its own {{Tag:feature|...}} syntax, where the feature can be also defined by translatable units (so a feature can also be made for a specific language!) or use its own rules for parsing, aliasing and resolving fallbacks!

And if you still think that French is complicate for you, just consider the case of Celtic languages (which have many more plural types) and Slavic languages (using complex rules, not based of the value but just on the two least significant digits of the integer part of the value, and that also influce the derivation of other words, notably their grammatical case!)

Ideally the Freecol solution could also solve the problem existing as well in languages using complex mutations and elisions (French, Italian, Celtic languages...), or complex agglutination and deagglutination (including verbal affixes in German which are also reordered ni the sentence), or rules depending on semantics of lexemes (which adopt variable forms, or have complex cases like "amour" vs. "amours" in French which changes from masculine to feminine when going from singular to plural, or the way English changes some "or" into a "nor" in some negated phrases...). Those linguistic subtle things are discussed since long in CLDR (but still not solved as there was no working implementation, only some specific code used in specific applications, so resolving that issue was postponed), but with the newcoming Wikimedia projects for "Wikifunction" and "Abstract Wikipedia", we'll definitely have to work on that, and we'll need to create a more formal specification that will allow translation validators to really work (while preserving the compatiblity with existing i18n libraries and tools)!

По поводу этой правки - а что, есть причина, по которой не используются переменные tvar ? По идее, оба непереводимых фрагмента с тегами нужно просто спрятать от переводчиков за $1 и $2.

Нет причины, просто не озадачивался этим. Раз непонятно, уберу в переменные.