User talk:Verdy p

Jump to navigation Jump to search


Thread titleRepliesLast modified
Please stop revert war823:25, 7 March 2018
Portal:Zh514:04, 31 January 2018
Chiffres et espaces insécables118:15, 13 November 2017
Thank you223:17, 6 September 2017
Feedback for new search translation features123:11, 17 July 2016
page initiale d'où est issue la phrase à traduire ?123:05, 17 July 2016
Traduction de MediaWiki : pluralité320:05, 10 May 2016
Changes to message's documentation722:04, 10 April 2016
Traduction de "Wikimedia Foundation"121:20, 24 March 2013
catégorie:exclure lors de l'impression011:26, 12 December 2010
Thanks for your assistance with French for Mifos205:34, 22 November 2010

Please stop revert war

Please stop reverting MediaWiki:Mwe-upwiz-license-cc-zero/qqq. I tried the things you suggested in there and they do not work. It is not acceptable to suggest translators do things which do not work.

So, please please remove suggestions now and file a task in Phabricator or request in Support to make it possible to use localised urls in these messages in a way that works and is supported.

Nike (talk)14:53, 12 February 2018
Edited by author.
Last edit: 16:32, 12 February 2018

I've said already that the simple replacement (i.e. deletion) of "$2" to translate these was NOT working: you can type a translation like this, it is recorded but immediately marked as "FUZZY" meaning that what you do has the same effect as deleting a translation completely.

The top banner indicates we want to have these translations including adapting the URL. So that's what you want to, but your way does not work at all and will never work.

But "$2" has to be kept somewhere (at least in a comment or otherwise made visible): the translate tool ensures that all original placeholders are present, and if any one is missing, the translation is marked as incomplete/fuzzy and not used at all: the effect is that people will effectively see the untranslated English text as a fallback.

Since the begining this is what I want to avoid. For now what you do is exactly the same has saying that these resources are completely untranslatable and will remain in English for all !

Please suggest something that allows NOT including "$2" without marking the transaltion as "fuzzy" because it is missing : this does not exist for now in the translate tool to mark a variable placeholder as "optional", or explicitly replaced by another content than what is defined in the "var": for now the only existing way is to place the $2 in comments or make it visible.

I don't know why the Upload wizard complains about the presence of HTML comments in resources, when everything else in MediaWiki works like this. May be if HTML comments does not work, the wizard will accept "" with an empty string result, but I doubt it will work if the Upload Wizard in facts performs its own parsing of the resource and expects a format that the Translation tool is currently unable to deliver anywhere.

So yes I suggest fixing the UploadWizard code so that it will parse the wikicode or standard HTML correctly and will not buildup some incoherent presentation of what it contains.

Note that I have not "reverted" things, but documented what was working and what was not, in order to explain (and demonstrate to you) that your attempt was failing all the time.

Initially I placed the HTML comment just after the "[" before the URL, someone said it was parsed by the UploadWizard incorrectly, then I tried to place the $2 AFTER the link (completely outside of it). Waht the UploadWizard does is some internal tricky magic transform, but you've not proposed anything that allows the Translate tool to accept any one of the translations you submitted: in all cases we saw "incomplete translation" statistitics, and many users have tried something; only what I propose is for now aceptable for the translate tool.

We absolutely need a solution to fix either (or both):

  • The UploadWizard (so that it correctly handles the HTML or wiki content and does not reencode it in a non-standard custom way);
  • The translation tool (to mark a variable placeholder where a translation wants to explicitly replace its content without marking the translation as "fuzzy" because it is missing);

otherwise we will never see the correct translations expected (not even yours !).

Note that for URLs to Commons licences all the replacement URLs have the property of sharing the same prefix (and it is the content of $2) but we cannot "glue" "" just after $2 because of the current supported syntax of placeholders; if we use "$" the Translation tool will think we want to use a non-existing variable named "2deed" (so the transaltions will be also marked as "fuzzy" and the translation package will remain "incomplete", not 100% translated) :

This is also a defect of the Translation tool which offers no clean way to indicate explicitly where a "$variable-name" is terminated in the translated resource. I think it should support "${2}" here (like in Bash command files where this extended syntax is used for that purpose to avoid the tricky escaping) or more generally ${variable-name}, or the alternative syntaxe "%2%" (like in DOS/Windows command files) which is probably simpler to type (the set of characters allowed in variable names between the "%"-pair should be only letters, digits, or some only punctuations: underscore, hyphen, colon, excluding controls and whitespaces, semicolons, commas, full stops, percent, question marks, exclamation marks, single and double quotation marks, and probably others, otherwise there will be "false positive" detection of dummy variables in translated items).

My preference would be the syntax using paired punctuations with ${variable name}, but other suggestions are possible: $<variable name> or $[variable name] or $(variable name) or $"variable name" or $'variable name' (this solution is more liberal on the set of characters we accept in variable names used in translatables source).

Verdy p (talk)15:59, 12 February 2018

Placing a html comment anywhere in the string does not work. That is worse than having the link point to the English version (which has a language selector).

If you want to deviate from the excepted translation (link pointing to the English), you must file a bug or support requests. Suggesting hacks that do not work is not acceptable.

We also export fuzzy translations, so your assumption that fuzzy translations are not exported is not correct.

As a site admin, it is my duty to ensure our translators get good advice, it's not my duty to fix i18n issues in the products.

I'll try to make this very clear: altering the message documentation or translations to work around i18n issue is NOT OKAY. The proper process is to report i18n issues to the developers so that they can make a proper solution.

Nike (talk)16:31, 12 February 2018

"fuzzy" translations will be edited all the time by any translator. You should not use them as a trick in the Upload Wizard. It is really a bad solution which will constantly drive translators to try fixing them.

So what you're saying to translators is to use a trick to insert fuzzy translations that won't be checked at all. No one on TranslateWiki (except you) expect these "fuzzy" strings to be effectively correct. But as you manage this wiki, you should be interested in fixing the hosted Translation tool to support more explicit variable name termination, or marking a required variable as "used" with an empty replacement value which will be absent from the export (but only if the project to translate accepts such absence by explicitly marking a placeholder as optional: this is not the case for many projects that expect ALL placeholders to be present, notably placeholders for C/C++ format strings, an absence of the placeholder causing severe software bugs such as null pointer exceptions, or using integer values in other placeholders as if they were pointer values, causing security breaches such as making local variables hidden on the application stack to become visible).

Please fix the Upload Wizard (it should not use any fuzzy translation at all). Only this Wizard does not follow the MediaWiki wellknown practices and uses custom parsing deviating from recommendations. HTML comments are not "tricks" they are part of the Wiki standard since ever ! but using "fuzzy" translations IS A REAL TRICK which should never happen with TranslateWiki (which should even better not export them at all, they are fuzzy for various reasons, including incorrect syntax, missing required placeholders, unmatched paired punctuation, incorrect encoding,... !)

And the proper way to report i18n issues to developers is via the editable /qqq documentation that they will get from TranslateWiki exports along with translated items for all languages ! This is used in many projects to report cases where there should be plural forms, or genitive forms, or gender variants. Other ways to report these issues are nearly impossible to find in the interface and varies from project to project (there's no standard way to indicate where to submit these issues).

Verdy p (talk)16:37, 12 February 2018

The real truth is that the new UploadWizard is incorrectly parsinf the "[$2 legal text]" which is supposed to be an external link in the Mediawiki syntax, as if it was a wikilink (normally with the syntax "legal text") and then uses the first parameter of the link (the URL "//") by prepending it directly to the base URL of the wiki pages). It is already broken including in English as the final URL (in the generated HTML) is also invalid as it gives (for example on Common) the following HTML code:

  <a href="">

For doing this, it makes a special simplified parsing of the translated item. Then it checks the "weakly parsed URL": if it starts by "//" or "http://" or "https://", it won't prepend the base URL of the wiki, but will use that URL directly as is (once again without looking if there are HTML comments or even if in fact its syntax is invalid); if the "weakly parsed URL" starts by anything else, it assumes this is a a FULLPAGENAME, and so it will prepend the wiki's base URL for articles.

Only then it will start converting this broken code using MediaWiki parser to generate the HTML and finally the link.

So the presence of "" at start of the url using the syntax "[url text]" effectively does not work (this was the initial report, concerning ONLY the new broken UploaWizard deployed on Commons, but not the previous one on all other wikis), but the suggestion to put it outseide the link really works: my suggestion was correct, it fixes it and is compatible with BOTH the legacy UploadWizard and the new one (even if the later is still using a severely broken code), and it does not require any fuzzy translations (that are NOT used at all, I can confirm it, they are replaced by the original untranslated English text!)

The only working translations are those using "[$2 some-translated-text]" (e.g. the translation in Chinese) **without** following the indication to localize the URL (this inidcation was not added by me it was a desire to localize it given by the UploadWizard authors themselves (and of course the origional "[$2 untranslated-English-text]". So Chinese does not follow the top indication given to translators in a bold red text at top, and does not attempt to localize the URL at all.

The bug is not in translations, but in the new UploadWizard implementation (as used on commons but not all wikis which still use the former non-broken UploadWizard), it exists independantly of my suggestions or even if one uses the "fuzzy" translations that have removed "$2" and placed another URL there (in which case the fuzzy translation is NOT used at all by former implementations of the UploadWizard in all other wikis).

The bug is really in that new version of the Wizard, not working at all on Commons, whatever we put or don't put in these translations (the new version works ONLY in English where localisation of the URL is not used, even if it could be there to point to the "deed.en" version instead of using the automatic langague selector in CreativeCommons, which may display another language than English, depending on language settings of the webbrowser used to navigate, which may not be always the user's prefered language if the local webbrowser settings cannot be changed by that user, or may not be implemetned at all on some devices not transmitting any "user language" preferences to the web server, or because these browser settings are cleared by privacy tools installed on the same device as the webbrowser).

My suggestion to put the dummy placeholder "" completely outside the link is correct (yes I tested it, others that pretend it does not work have in fact NOT tested it), and fixes the issue, even before the new broken UploadWizard (insufficiently tested) is fixed and it works with legacy implementations of the wizard on other wikis (i.e. most Wikipedias that allow importing images locally instead of on Commons, and almost all non-Wikimedia wikis).

My suggestion is not a hack as you think, it avoids having to use any fuzzy transaltions that are normally rejected everywhere in MediaWiki (replaced by non-fuzzy fallbacks or the untranslated text).

But yes a better solution would be to be able to instruct the "TranslateLinter" used on this wiki to mark the placeholders that are optional, or that can be safely repeated (i.e. instruct if a variable has 0-n occurences allowed, instead of just 1 by default), or that can be safely reordered (most placeholders in C/C++ such as "%s" or "%d" are not reorderable), or that can be modified (e.g. formatting options in C/C++, e.g. for formatting dates or for currency amounts with a different number of decimals: this kind of linting is complex to instruct, and shoudl not be the first pritority you'll want to work on). With just the "occurences number" linting instruction saying that 0 occurences is allowed, the linter will accept the absence of a placeholder in the translation, and will then not mark it as fuzzy.

Summary: fuzzy translations are ALWAYS undesirable they ALWAYS need to be fixed on this site; but saying to project maintainer to still use them will cause much troubles and much more severe bugs in applications, so your suggestion is a real HACK.

Verdy p (talk)19:03, 12 February 2018

There is way to have Translate not mark translations with unused variables as not fuzzy if this is reported . There is also a possibility that this issue will be fixed in UploadWizard if it is reported to the developers in Phabricator.

Again, it's not my duty to fix UploadWizard.

Again, qqq is not the way to communicate with developers. That's what the "Ask question" button is for. It will leave a message in this wiki, which can then be relayed to Phabricator, if necessary.

But all my time goes into trying to make you understand this. I am going to revert the changes to the message documentation since you did not do it. I will block you if you will try to add them back again.

Nike (talk)08:48, 13 February 2018

Please, do not add links to /zh, that's disabled here.

Liuxinyu970226 (talk)04:14, 31 January 2018

Also, your currently edits result some unexpected problems, e.g. in Portal:Ug, it resulted links like and, where the "U", "L" and "C" are capitalised, but the actual URL ( ) require all lower cases.

Liuxinyu970226 (talk)04:20, 31 January 2018

And suddenly, this is another unexpected issue that I've found, after those changes, in Kazakh portal page, the links after "Cyrl" and "Latn" appear, but links after "Arab" ( and, which is the first ISO 15924 value, are missing.

Liuxinyu970226 (talk)09:26, 31 January 2018

Now use "15924-1=" instead of "15924=" when the default ISO 15924 script is not implied and the language code must be suffixed by a script code or variant code.

This solves the 3 cases: Kazakh ("kk" disabled need "kk-cyrl"), Uighur ("ug" disabled need "ug-arab"), and Chinese ("zh" disabled need "zh-hans").

If translations can still be done one unsuffixed language code (in its default script), AND on suffixed language code, use

  • "|15924=Scr0" for the default implied script (ambiguous/mixed),
  • "|15924-2=Scr1" for the *first* script
  • "|15924-3=Scr2" for the second script

But normally we should have only:

  • "|15924-1=Scr1" for the *first* script
  • "|15924-2=Scr2" for the *second* script

Variants are not impacted.

I documented this case in the template to make it more flexible

Verdy p (talk)10:56, 31 January 2018

"zh" is now disabled by assigning it the default script code "|15924-1=Hans" instead of "|15924=Hans" (before it was even "|15924=Hani" but it is disabled too, this script variant is not recognized).

Using "|15924-1=*" enforces the use of a script code suffix even for this default script.

Verdy p (talk)14:04, 31 January 2018

Chiffres et espaces insécables

Salut !

Les conventions typographiques de Wikipédia citent à juste titre le Lexique des règles typographiques en usage à l’imprimerie nationale : « Un nombre en chiffres arabes ou romains ne sera jamais séparé du nom qui le précède ou qui le suit. »

Il n’était donc pas nécessaire de la supprimer comme tu l’as fait.

Bonne continuation !

Pols12 (talk)16:53, 13 November 2017

si c'est un numéral, l'espace insécable n'est justifiée que devant une abréviation ou un symbole d'unité, pas pour un nom ou groupe nominal accordé de façon régulière comme un mot.

Dans "Les 12 hommes" il n'y a aucune espace insécable, pas plus que dans "12 octets" ni dans "65 millions d'habitants" ni après les derniers chiffres de "65 000 000 habitants" où seuls les groupes de chiffres sont séparés par des fines insécables. L'espace insécable (toujours fine entre les groupes de chiffres, ou avant une abréviation ou un symbole d'unité **invariable**) n'est donc pas justifié du tout ici.

Cas particulier: uniquement les romains quand ils sont un ordinal après un nom sont insécable du nom qui le suit (cet espace n'est pas une fine) : "Article<NBSP>Ier", "chapitre II", "Elisabeth<NBSP>II", mais sinon en tant que numéral non ordinal les romains sont sécables comme des déterminants ("un livre" ou "1 livre"). Cependant une règle de style *contextuelle* évite de laisser orphelins le nombre et le nom seulement s'il y a un ou deux chiffres, donc "12<NBSP>francs" mais "123<SPACE>francs" et "12<FINE>000<SPACE>francs".

- <SPACE> c'est une espace sécable justifiable normale (le séparateur de mots, d'au moins un quart de cadratin) - <NBSP> c'est une espace insécable justifiable normale (d'au moins un quart de cadratin mais souvent plus avec des polices "larges" et un demi-cadratin comme les chiffres/lettres en police à chasse fixe : sa largeur suit celle des autres espaces sécables) - <FINE> c'est une espace insécable non justifiable fine (d'au plus 1/5 de cadratin, souvent 1/6, parfois 1/8 avec des polices étroites); cette espace ne se justifie normalement pas, sauf dans des présentations à colonnes de texte très étroites si les autres espaces justifiables sont étendus au delà de 1 cadratin... et seulement après avoir joué sur l'interlettrage (l'approche) entre tous les caractères (lettres, chiffres, ponctuations, espaces) sauf entre caractères liés sans interlettrage qui doivent rester collés et qu'on le peut pas lier non plus par un trait de jonction cursive qui peut être allongé de la même façon que l'interlettrage): la fine respecte la proportionnalité dans ce cas, mais l'interlettrage dynamique est compliqué à mettre en oeuvre pour la justification totale des paragraphes entre les deux marges.

Sans interlettrage dynamique pour la justification totale, la <FINE> a une chasse fixe (contrairement à <SPACE> qui lui absorbera tout pour aller jusqu'au cadratin avant de combler le reste de façon équitable entre tous les caractères y compris <SPACE>, <NBSP> et <FINE>)

Attention donc au contexte d'utilisation: le wiki n'est pas un cas d'utilisation en colonnes de textes étroites. Mais même dans ce cas (exemple : utilisation dans des colonnes de tableaux, l'espace entre "12 octets" en toutes lettres sera bien sécable, contrairement à "12<FINE>o", ou "12<FINE>€").

Ce que dicte réellement l'imprimerie nationale dépend du contexte: l'impression des textes de loi (très verbeux), impose de gagner de la place pour la version journal, et "12<SPACE>octets" sera sécable de la même façon que "12<SPACE>septembre" où le nombre est pourtant un ordinal (adjectif d'un nom "jour" sous-entendu) et non un déterminant cardinal du nom "septembre". La mise en page dicte pas mal de chose mais sur le wiki elle est imprévisible et on doit prévoir le pire: il n'est pas justifié d'empêcher la coupure de ligne entre le numéral cardinal utilisé comme déterminant. Et même pour éviter les cas de nombres "orphelins" séparés du nom à la ligne suivante ce n'est pas le codage qui jouera mais un paramètre de style fixant la largeur minimale qu'on peut laisser orpheline: cette largeur minimale s'applique aussi sur le dernier mot de fin de ligne, mais "bonnet de nuit" peut tout à fait être coupé sur chacun des deux espaces avant et après "de"; et dans "[...] Il cria : de l'eau ! [...]" on peut tout à fait couper avant ou après "de". Les règles de style évitent de couper les phrases si possible pour n'en laisser qu'un seul mot court (moins d'un cadratin) séparé, mais là encore il n'y a pas de différence de codage entre les espaces séparateurs de mots selon la position dans les phrases: c'est le moteur de rendu qui déterminera les espaces les plus appropriés à couper mais il n'y a aucune espace interdite à priori (donc pas besoin de marquer comme insécable).

Dans "12<FINE>o", ou "12<FINE>€" on a une une unité abrégée ou symbolique: là c'est bon de prendre une fine insécable (non ce n'est pas un <NBSP> !) De même les espaces devant ou derrière certaines ponctuations («»:!?) sont des <FINE>.

Verdy p (talk)18:15, 13 November 2017
a piece of the cheese

Hoi, I blogged about the great work you did for Mifos. It is really important and appreciated.. Please continue.. Thanks,

GerardM22:42, 21 October 2010

I'd like to echo Gerard's comment. Thank you! I'm sorry we aren't part of the translation rally.

Meonkeys23:03, 21 October 2010

Actually, as opposed in what you assumed, I was not competing at all for the WM translation rally at that time. Such competition looks a bit stupid for me, I don't care about getting a rank, my interest will go where I think my help could be useful and appreciated.

This was the case for this one because at that time the project was starting and very few WM users were interested in it, exactly because they were just competing for the WM rally, not me, and many of these new rallied translations were in fact poor and required many corrections later after review, to be coherent in terminology or to solve bugs and ambiguities or even for correcting lot of basic orthographic or grammatical errors, or worse complete misunderstanding or generated pages that are completely unreadable/unmeaningful after such speedy translation process: in such rally the transaltors translate as muc has they can, one string after the other, without taking care of the context of use, and they don't care documenting or discussing ambiguity problems that very frequently exist in English (notably because of non explicit grammar, abuse of WM-specific English jargons, or many very different meanings of the same orthographic term).

I'm not perfect, and others may still have a different opinion on the best way to translate things, and some other changes in each project may require adjusting some terms if they create new ambiguities. But now MIFOS has been gradually and slowly adding only small additions, and its French translation state is easily kept at 100% by various translators doing that slowly and more carefully for specific cases where it would be needed to check the meaning or adjust the user interface to keep it easily usable by MIFOS users.

Verdy p (talk)23:17, 6 September 2017

Feedback for new search translation features


We have introduced new features in Search Translations. Please read about it in phabricator or test wiki. It would be really helpful if you could give us some feedback about the new features in Search Translations.

Thank you and we shall be waiting for your feedback.

Phoenix303 (talk)05:36, 15 July 2015

Unusable: the tests links (including those listed in Phabricator) return an error 402 (Bad Gateway). This test server is actually not working (or not reachable from the public Internet, possibly only in the WMF internal LAN: possibly a problem in configuring routings, or firewalls, or some DNS).

Verdy p (talk)23:09, 17 July 2016

page initiale d'où est issue la phrase à traduire ?

Beaucoup de traductions sont annulées car vous ajoutez une explication qui ne figure pas dans la phrase à traduire. Comment peut on remonter au contexte où la phrase anglaise est utilisée pour mieux coller à l'idée que l'auteur a voulu transmettre et ainsi orienter la traduction ? Merci. Christian, 92.

Christian (talk)18:39, 17 July 2016

Note: "l'auteur" n'est pas tout seul sur Wikimedia ou MediaWiki, il peut s'être lui-même trompé dans la version anglaise: il n'y a pas que le message à traduire verbatim, il faut comprendre où et comment il est utilisé (et la doc à côté mentionne l'usage: il suffit de regarder). Il est alors justifié de sécarter du texte anglais (qui sera corrigé séparément). Coller absolument au texte anglais (surtout quand il est faux car il a été mal interprété même dans son original) est contre-productif.

Verdy p (talk)23:03, 17 July 2016

Traduction de MediaWiki : pluralité


Je reviens au sujet des 3 modifications que j'ai effectuées que vous avez annulées :

(Cela m'étonne d'ailleurs qu'il n'y en ait que trois puisque je croyais en avoir fait plus que cela de cette manière.)

J'ai bien compris le système de {{PLURAL}} à la lecture des traductions existantes, toutefois je pensais mieux coller au texte original avec ma traduction car le cas du zéro n'était jamais pris en compte dans ces messages (et les utiliser avec un zéro donnait des phrases incorrectes en anglais). J'ai donc supposé que ces messages n'étaient jamais utilisés avec le cas zéro. Je pense que cela se voit particulièrement dans la deuxième modification, où once ne peut correspondre qu'à 1. Pour ce même message, il m'est avis que la distinction du cas « une seule fois » nécessitera un effort inutile de la part du lecteur lorsqu'il verra un message avec un format un peu différent. Si l'on peut éviter de distinguer des cas, il vaut mieux le faire. En anglais, on dit également rarement two times et pourtant le cas twice n'a pas été distingué ; seulement le cas du 1 puisque sinon il y aurait eu une faute de grammaire.

En espérant obtenir plus d'explications, bien cordialement,

Frigory (talk)18:55, 9 May 2016

Pourtant j'ai bien vu le cas "0" qu'il est utile de distinguer plus clairement (par une phrase négative ou "aucun"). Je ne vois pas ce qui empêche un message de clarifier (et même en anglais on trouve aussi cette distrinction du 0 et du 1, indépendamment du singulier ou pluriel).

Je ne vois pas ce qui pourrait demander plus d'effort pour le lecteur que de voir directement le cas 0 clairement sans avoir à distinguer un chiffre. Surtout que la traduction qui existait présupposait que le singulier était forcément "1" (vrai en anglais, car zéro y est pluriel, mais faux en français). La distinction est nécessaire pour ne pas lire "un" alors que ce devrait être "zéro".

Ce qui est distingué en français n'a pas à l'être en anglais de la même façon. Oui la grammaire est différente, mais dans les deux cas on peut distinguer le cas zéro soit du singulier générique en français, soit du pluriel générique en anglais.

Ca donne donc {{GENDER:$valeur|0=cas zéro|singulier|pluriel}}

Le nombre de cas à distinguer varie selon les langues les traductions n'ont JAMAIS l'obligation de suivre le modèle anglais (en russe par exemple il y a d'autres nombres que le singulier et le pluriel, en indonésien il n'y a pas de distinction de nombre). On DOIT adapter le nombre de formes dans GENDER selon la langue et en suivant ses propres règles et pas celles de l'anglais.

Verdy p (talk)21:21, 9 May 2016

D'accord pour la deuxième modification annulée alors.

Par contre, pour les deux autres, je persiste. L'idée n'est pas de se plier au modèle anglais mais de constater que ces messages ne sont jamais utilisés avec le cas zéro (tu sembles dire que c'est le cas : « et même en anglais on trouve aussi cette distrinction du 0 et du 1 », mais je ne vois pas où). Le contexte est d'ailleurs « This message is displayed at the top of a category page showing the number of pages in the category when not all pages in a category are counted. » qui semble dire que le message est utilisé pour indiquer le nombre de pages listées lorsqu'elles ne sont pas toutes affichées, certainement parce qu'elles sont très nombreuses. Donc j'ai du mal à croire que le cas du zéro soit utile ici.

« Je ne vois pas ce qui pourrait demander plus d'effort pour le lecteur que de voir directement le cas 0 clairement sans avoir à distinguer un chiffre. » → Je parlais du cas « une seule fois » par rapport à « 1 fois », mais bon, j'abuse un peu. Je suis partisan du KISS ici.

Frigory (talk)20:02, 10 May 2016

C'est pourtant le cas justement quand on navigue d'une page à l'autre : on se retrouve parfois avec une page sans éléments.

Verdy p (talk)20:05, 10 May 2016

Changes to message's documentation

Hello. This changes (1, 2, 3 and 4) should be reported to phabricator, if you think they are needed.

Macofe (talk)04:31, 8 April 2016

It's simply not easy to locate where to report defects in source message, there are so many links to various places.

The easiest to report it is in the doc page (qqq) of each message (this suggests that developers are following changes to these docs when they create or update them), because the translation interface still lacks a possibility to comment changes, or to add message to the talk page associated to each translation (those talk pages, spread across multiple languages in separate are impossible to follow, but it is not impossible to follow the "qqq" documentation message.

Phabricator is not linked at all from translatewiki and not even in the "qqq" doc pages, which are also frequently empty.

I suggest to Wikimedia to create systematically a "qqq" doc page for each of their message, including a template linking to their Phabricator site on the appropriate section.

Verdy p (talk)04:41, 8 April 2016

It is actually very easy: The “Ask for more information” link under qqq goes directly to Phabricator. It used to go to Support, hence the label; I guess that it should be changed.

Amir E. Aharoni (talk)13:21, 8 April 2016

Actually there's NO such “Ask for more information” link under qqq...

Verdy p (talk)13:27, 8 April 2016

Yes there is.

See the red elipse
Macofe (talk)23:05, 8 April 2016

Not in the 4 qqq documentation messages listed above. You took an example in another message.

Verdy p (talk)23:51, 8 April 2016

Traduction de "Wikimedia Foundation"

Salut, je viens de re-vérifier les traductions de Donation Interface (j’ai fait beaucoup de typo/espaces insécables, ça floode un peu les modifications récentes pour pas grand chose).

J’ai remarqué que tu traduisais "Wikimedia Foundation" par "Fondation Wikimedia", alors que je préfère garder l’original. Est-ce qu’il y a des directives particulières là-dessus ? (conserver l’original, translittérer uniquement, ou toujours traduire) Je me pose souvent la question, et j’ai l’impression que les pratiques varient selon les traducteurs.

Seb35 (talk)17:51, 24 March 2013

Il y avait les deux avant que j'y touche, j'ai pris la dénomisation le plus courante utilisée pour unifier ça. Dans les descriptions simples la traduction est admise, mais comme cette traduction affiche des mentions légales, effectivement la dénomination officielle de la destination du don est préférable (je me demande si les noms anglais non traduits ne devraient pas tous être en italiques avec pour indiquer que ce n'est pas traduit et que c'est repris verbatim (pas nécessaire si on conserve les majuscules). Mais dans les expressions déjà simplifiées en anglais "the Foundation", il me semble qu'on doit traduire (et sans doûte supprimer la majuscule : plutôt que d'écrire "la Foundation", cela devient "la fondation").

Verdy p (talk)21:20, 24 March 2013

catégorie:exclure lors de l'impression

Bonjour. Je te signale, par courtoisie, que j'ai annulé ta modification sur MediaWiki:Coll-exclusion category title/fr. En effet, l'usage de l'apostrophe typographique aboutit à la non-reconnaissance de la catégorie par l'outil de génération de PDFs. Une correction a dû être faite en local sur fr.wikipedia. Je ne sais pas combien de temps il faut pour que les messages systèmes soient mis à jour sur les projets. Sais-tu combien de temps l'outil de génération de PDFs restera cassé ? Il serait probablement bien d'avertir les projets francophones, avant qu'ils ne s'affolent. Bien à toi,

Dodoïste11:17, 12 December 2010

Thanks for your assistance with French for Mifos


I too want to wish you thanks for your translations of Mifos thus far. Thanks for coming back to finish the remaining messages in TWN. I also wanted to see if you could help in translating approximately 300 untranslated messages in our old .po files that aren't yet translated. Email me at and I'll provide details on how you can help.

All the best,


Edcable22:17, 19 November 2010

I just completed the few messages that were added since my last edits session, and checked the new FUZZY messages. Go and see yourself for the import.

Did you import the last messages made during last month on your test server ? I'd like to be able to see a better review in situ (just to make sure that they are accurate, or are displayed properly, or that there's no unexpected incorrect meaning assumed, or to fix a few minor things like capitalization.

The last time I checked your test server, almost everything in the French locale was extremely fuzzy (and almost unusable as such).

Did you see that I have created a separate user account (mifosfr) for the French locale, with an alternate administrator status, just to be able to see all messages, and avoid corrupting the default administration user account (where other languages may be mixed) ?

Note: I'm speaking here about your current test server at (Mifos release E, unstable, the only demo server available with a French locale according to your page ""), which is currently hosting severely broken French localization and whose content still does not displays any one of the Translatewiki translations.

But may be you'll setup a new separate demo/test, and it would be useful to have a test server in sync with these translations made in TranslateWiki, or at least those that are complete enough to be completed, and that are discussed here the the various translation issues and the code fixes that you implemented in your code to support these translations.

So I suggest you develop a code branch for each package submitted to Translatewiki, so that you can synchronize these translations easily, before merging them in your new main branch and preparing the next snapshot for the messages. It would really help us a lot here, otherwise all this work performed here will be constantly lost and will have to be performed again without being able to find a synchronization. If you setup such test server, please point us here on the page for the MIFOS project, so that translators can see which translation were imported/exported, and where you can announce those translation packages that have come live on this test server for evaluation.


Verdy p22:35, 19 November 2010


Thanks for the quick reply. I didn't realize this message had come through TWN so I'm just getting it now. On Monday I'll talk with our team about getting that French instance set up.

Between now and Tuesday do you have time to translate missing messages from our old .po files. Details on where to find and how to translate can be found at:

And what is your mailing address. I want to ship you a signed copy of Alex Counts' book to thank you for all your contributions.

And as we get more of the UI phased in, we'll continue to seek your help :)


Edcable05:34, 22 November 2010