On peut fusionner les modèles en se satisfaisant de paramètres, par exemple

• {{ fr-conj | groupe = 1 | march | maʁʃ }}
• {{ fr-conj | groupe = 1 | terminaison = eler-elle | app | a.p }}

Par contre je préférerais ne pas laisser le modèle déduire la conjugaison tout seul : mieux vaut plutôt faire la liste de tous les cas spéciaux (=autant qu'on a de modèles) et les définir dans la liste des paramètres à remplir avec le TemplateData. Il y a trop de cas particuliers pour laisser le code deviner tout seul (le code deviendrait inutilement lourd). Mieux vaut être explicite.

Ok so how about this:

• The tag/tracking task in this initial request is pretty low priority for most people, and I don't think it is really useful in the end by itself: there are very few watchers, and only a handful of tasks that are rarely ever worked on. So I would suggest we just get rid of it and keep those tasks in the main All-and-every-Wiktionary project, like it should.
• More importantly for us, we'd like to have a dedicated project for the French Wiktionary community, in which we'd be able to organize tasks for French speaking contributors, for us to tackle ourselves (and in French, for accessibility).

I'm reopening this task per the above comment: this is not a duplicate of T101948 .

The subject is actually not the same: the task T101948 relates to tasks related to the French Wiktionary but that require an external work (i.e. technical changes to Mediawiki). The target of the tasks are Wikimedia developers/maintainers/admins. The corresponding task request to ask for a tag is correct.

Dans T101948#3418920, @Framawiki a écrit :

I think that #French-Sites will be perfect, with a column Wiktionnaire on the workboard.

I don't have a strong opinion on this matter, if only that "French_Wiktionary" may seem too English-centric and not necessarily welcoming for non-English speaking people, who are the target of the project. But if there is a convention to follow for this as you've pointed out, then we need to follow it.

In T165061#3281823, @Thibaut120094 wrote:

Btw, [[’]] should only show interwiki links to [[’]], not links to [[’]] and [[']] like on https://fr.wiktionary.org/w/index.php?title=%E2%80%99&oldid=23047369
[...]
Showing two links for the same language doesn't make any sense for the reader (see capture).

I added manual interwiki links in the linked page: as a result all language links are unique (just like for [[...]]).

@Wikitiki89 Do you have examples of a Foo... <-> Foo… article (or with different apostrophes)? The only articles I can think of would be those about the character themselves.

In T164059#3223261, @Billinghurst wrote:

Maybe it is connected with wikidata? Only way that the two are connected.

I did the same and the one category that failed was "Catégorie:Suppressions immédiates demandées", which is the exact equivalent of "Category:Speedy deletion requests" on fr.wiktionary.

If I deactivate "Hide page categorisation" in my watchlist preferences, the page is correctly displayed. It goes back to blank if I reactivate the parameter.

Some interesting stats would be:

• How many words are in all/most Wiktionaries?
• How many words are unique to each Wiktionaries?
• What is the overlap between 2 Wiktionaries (e.g. fr vs en)? Or 3, 4 (Venn diagram)?

After some thinking, unless the pages are equivalent for Cognate ( e.g. [[fr:y’a]] and [[y'a]]), we should indeed expect X:Foo to link to Y:Foo, no matter if it is a redirect or not.

This is a convention in the English Wiktionary (and the Japanese one I think) that is different from e.g. fr.

That looks too complicated for Cognates.

Thanks @Lea_Lacroix_WMDE that's good enough!

@Addshore Do we have an ETA for when the extension will come into action? Just so we can prepare accordingly (e.g. for interwiki bots).

Depends what you mean by "complex wiki markup". Most project pages use basic wiki syntax (e.g. tables), with very few templates.

The French Wiktionary is currently using the fixed list approach for languages, administered by the community. We use ISO codes to represent languages almost everywhere (e.g. the title of a language section is {{langue|fr}}, which is displayed as "French"). We do not have identifiers for dialects and we usually use a geographic term. Not sure if those should be as controlled as languages.

The current tool uses a more complex database primarily designed for the custom search in https://fr.wiktionary.org/wiki/Wiktionnaire:Recherche_avanc%C3%A9e. That tool is way more complex and requires to parse the xml dumps to get data (with a dedicated set of scripts).

Maybe I read the code wrong, but we don't want to normalize the case of the words, e.g. "Clause" and "clause": the interwiki from [[de:Clause]] to [[ar:clause]] is wrong.

@Octahedron80: Don't forget to link to the discussion on km.wikt. This kind of change requires a community consensus (i.e. a vote), so the link can be used to check that.

Do we need a vote for this?

In the French Wiktionary our rules would make xoá and xóa in two different articles, with a soft redirect to the corresponding content. The rule of thumb is that hard redirects shouldn't imply any linguistic information, e.g. a variation is informative and should be explained explicitly if both articles.

Here is an update! See details here https://fr.wiktionary.org/wiki/Utilisateur:Darkdadaah/Analyses/Interwikis.

Some wikis have a "(private data)" in https://dumps.wikimedia.org/backup-index.html: a similar "(closed wiki)" label would work.

That sounds very much like Google street view (you may get the same problems they had too, i.e. mandatory blurry faces).

Most closed wikis are basically empty, I don't see any use for their dump for anyone, up to date or not.

@gabriel-wmde I did some work like this a long time ago, see https://www.wikidata.org/wiki/Wikidata_talk:Wiktionary#First_and_second_phases. I'll see if I can do an update...

In T110340#1578520, @Bugreporter wrote:

However I still think users should be able to opt in even if the site decided to opt-out - the site should hide it by default, instead of disable it completely.

For what it is worth, "quantity" seems just fine to me. Both a measurement and a count can give a value for a given quantity. Also, a measurement is not only an event, but also its result, so there is no need for a "MeasuredQuality".

That was quick, thank you!

In T109633#1556869, @Aklapper wrote:

Please explain why to disable watch category membership by default.

Now I just need to write a bit more doc for the API.

I don't have this problem anymore ; I can't say since when. I suppose I should close this bug then, although I would have like to know where it came from.

This is a local en.wiktionary issue: you should ask directly here: https://en.wiktionary.org/wiki/Wiktionary:Grease_pit.

Mediawiki cannot apply a rule for a language without knowing what is the expected language. Writing a pagename only in the url is not enough, and you should not expect the server to generate a redirect from it.

About the naming: I just proposed to create "Wiktionary-fr" (T101948). This naming schema seems the most logical to me:

• it shows its hierarchy (subproject of All-and-every-Wiktionary), like other projects, e.g. Toolforge / #Tool-labs-tools-anagrimes
• it is the easiest to find with autocomplete: everyone searching for specific fr.wiktionary bugs will try to write "Wikt" first, which will offer All-and-every-Wiktionary and the other "subprojects".

So the naming schema would be (based on the url of the website) :

I can't reproduce this bug anymore on both Firefox 37.0.2 and 38.0 beta. It was still buggy with 37.0.1 and 38.0 (not sure if the beta was exactly the same).

@Ricordisamoa: I used a shortcut.

That's what Wikidata should do, but we are still far from it.

Here is a list of xdxf files created from a fr.wikt dump : https://tools.wmflabs.org/anagrimes/data/xdxf/.

Ah yes, I thought there was some hierarchy to projects, because the guideline mentions subprojects (here).

Is the interface of Phabricator only available in English? Because as long as it is, I don't see any non-English speakers writing tasks anytime soon, even in their own language.

Here is a screenshot, after I typed "Abcde" in the searchbox at the top of the page:

For now I added the fr.wiktionary task T76447 in a column "Language specific bug tracking" in the new project All-and-every-Wiktionary.

Is there a reason why only "main namespace" pages are mentioned in the above proposal?
Also, does this proposal takes into account the different ways the different communities represent words? E.g. different apostrophes used for aujourd'hui in French and in English (with corresponding redirects in each project).

The Book Creator doesn't seem to take into account the new setting (enable/disable) until I go to another page. If I go back to the same page, the setting remains ignored.

I removed blocking tasks that are more general than fr.wiktionary and that are already listed in the new Wiktionary project.