User talk:Verdy p/Archive 2012

Archives ^± : 2012 ; 2015 ; 2016 Jan-Jun, Jul-Dec ; 2017 Jan-May, Jun, Jul-Dec ; 2018

Changes to translation templates have invalidated hundreds of links to translations

Hi,

It seems like your edits to the translation templates has invalidated several links to other languages. Before your edits an article name could simply have the language code prefixed in lower case and not all caps, e.g. Da:Main Page instead of DA:Main Page. This is also what the Wiki Translation page mentions - the prefix list (left column) is explicit in lower case.

However now hundreds of pages will no longer show up in the language bar even though there is a translation present. Some examples:

Fi: Da: Sv: No: Pt: Bg: Et: ... and several other languages.

Fixed. Verdy p 16:12, 3 January 2012 (UTC)

To clarify: If you visit Fi:Bing there is a link to other languages, e.g. English, but from that page you can not go back to Finnish as FI:Bing does not exist.

I'm thinking of reversing these edits as it has caused a lot of dead links and the constraint of all caps is in conflict with the prefix list at the translation page. But if there is any reason for this new requirement, please mention so. I might have missed a discussion somewhere.

-- Findvej 17:38, 29 December 2011 (UTC)

Thereare tons of other broken/missing links too that imply the other convention. Most pages use the capitals, not the lowercase. That's what I was fixing, but yes this takes time to make them coherent. Verdy p 15:38, 30 December 2011 (UTC)

Was this change discussed and documented anywhere? And is anyone working on fixing the hundreds of links broken by this change? --Lyx 17:30, 30 December 2011 (UTC)

However the documentation still state that language prefixes are in lower case (besides actual wiki namespaces). Pages following this consistent rule as per documentation are now invalid. If there were broken/missing links then those should be fixed to be in accordance with the documented standard, not just changing a couple of templates without consulting relevant documentation and having a discussion about the change. If there was a proper discussion with a good conclusion then everything is fine. Otherwise I still see these template edits of being in conflict with the expected behaviour as per the documentation and could be up for a revert. --Findvej 21:38, 30 December 2011 (UTC)

Sorry, I have reverted your changes for now. Some or all of them can go back when they work. --Andrew 15:08, 31 December 2011 (UTC)

OK, I've noted that some codes dd not work for now. For this reason, I have now documented in the template code itself all incoherencies that I've found; most of them should be fixed though, as it has already created havocs everywhere, with missing or duplicated pages and categories that will need to be merged; I've installed some soft category redirects. More will come. There are also tons of categories without parents.

As a general run, the idea of autocategorizing pages within Template:Place is a very bad idea, when the category names are translated inconsistantly and depend on translatable items. This requires a kludge in templates to autodetect some category names, but currently, the categories are completely broken, and this does not help recollecting all the pages and subcategories that should be better categorized and named consistantly: It's much easier to maintain pages and categories when they are categorized explicitly, rather than by templates (the only exception is autocategorizing into "hidden" maintenance categories).

There are also lots of confusions between what is a language code and a country code. Language codes are only needed for the translation, but not for categorizing places.

As the wiki is growing, we need this cleanup fast, before it becomes a tremendous task to perform. If we leave this going this way, the wiki will soon become unmaintainable. This requires some radical changes, and there may be some unexpected artefacts, but this is unavoidable during the transition. I'll try not to break too many things, but thanks, instead of reverting all, just consider that this is part of an ongoing work in progres that cannot be made instantaneously (because it requires many searches before applying each correction, but even in this case, one solution will work for most pages with some exceptions still not working and that are getting fixed after that).

So I've made things gradually, and if someting gets broken during the unification, it's best to signal it to find a correction, but don't be too much worried about that, because I've also fixed a lot of other things that a single revert would make unusable. It's not my intent to break some existing links, but really to make the hole navigation usable. Thanks.

Note: I've very experienced in those category cleanups, I've done this ingrate task on Commons when it started be have overpopulated categories and images whose classificatin became completely inconsistant. I've made that notably when categorizing place names too, as well as fixing languages, resolving also multiple redirects. A consistant hierarchy really helps collecting and linking pages across the site itself, and has also helped other wikis to create their own hierarchy in a consistant way. The result was pages that were easier to find, document, and navigate, and with a much better indexing by external search engines, and the creation of various editing tools that helped categorizing pages better to create a richer set of related contents. Verdy p 16:12, 3 January 2012 (UTC)

Sounds like you have a plan, and your experience with working on commons sounds good. Looking at your changes, it looked like you were tackling performance of Template:Languages. I haven't taken the time to fully understand this template or the changes you're making yet, but I'm noticing that all pages are currently reporting 'too many expensive parser functions', so somethings not working well. Can you join in with a discussion over at: Template_talk:Languages#simplify the language template. -- Harry Wood 15:32, 4 January 2012 (UTC)

The problem appears to be that you’ve added a lot of languages to the {{Languages}} template and the extra calls to #ifexist are tripping the expensive parser function limit (though I’ve never understood why #ifexist is expensive and the red link check isn’t). One way to stop the problem could be to remove unused languages from {{Languages}} (but leave them in the backend) until someone writes a page in the language; note that Ka: and Lb: at least are in use although they don’t have main pages. --Andrew 18:26, 4 January 2012 (UTC)

No the problem is elsewhere. We should not use ifexist but a subpage of links instead to avoid the limit completely. All the languages I've collected are already found. I have written a workaround for most common languages to make sure they are found and displayed in the first list (notably Chinese), because the extra ifexist's are not evaluated and return false systematically above the limit threshold. This workaround works, but writing template subpages will take time to avoid displaying the red links in the second list. See what has been adopted on Wikimedia Commons, or in Wikimedia Meta (this will require a convention to be coherent, including taking into account the namespaces where they will be used, due to the exisiting dedicated namespaces, which I think was a bad idea where subpages would have been more appropriate; and including the Template namespace itself, which also has its own internatationalization). Verdy p 23:23, 4 January 2012 (UTC)

Taking on ideas from Wikimedia Commons and Metawiki may well be a good idea but the languages template has been changed to be more like them in the past and i fail to see how renaming pages would help. Andrew 12:45, 16 February 2012 (UTC)

Changes to my User:-namespace page?

Hey,

since when it is acceptable to edit another user's page, when it's under the User:*/ namespace? --Hanska 13:36, 2 January 2012 (UTC)

I've not edited your pages, only fixed double redirects as a courtesy, during clesnups of duplicated pages/categories and broken links. Verdy p 23:40, 2 January 2012 (UTC)

English translation missing in language bars

Hi! You've broken Languages template: English is not shown anywhere. Could you plz fix it? --Zverik 22:29, 2 January 2012 (UTC)

I've not touched English anywhere, but a couple of rollbacks were not synchronized... Unfortunately, there are tons of incoherences I have tried to fix, and this requires works, even though I also tried to avoid breaking things. I am alrready fixing lots of duplicate categoties/pages, and missing pages that are not found. This is not easy to fix all that, because there was no coherent convention before I tried fixing all those things.

Be patient, I'll fix as much as I can find, but who decided to mix the case conventions for language codes, creating the many havocs??? Verdy p 23:30, 2 January 2012 (UTC)

Thanks, I'll wait. BTW, here's a page for you to test prefixes (does not work correctly now): RU:Proposed features/parking:lane. --Zverik 13:21, 4 January 2012 (UTC)

Currently the language template is broken due to your experiments :( Please fix it, you know best what you did on your edits. Now it displays no suggestions for languages anymore and all pages are sued to use to many parser functions. Please use a sandbox for testing before you do to massive edits on a widely used template next time. --!i! 09:41, 18 January 2012 (UTC)

It worked ! I have reverted the broken edits that others have added after me (notably "User:Deutsch und Stolz" that added a German category at the wrong place! categories must NOT be added at end of templates, or only in the noinclude section; or better in the includeonly section of the documentation subpage). Verdy p 12:27, 18 January 2012 (UTC)

I reverted the edits of that user as it's some kind of vandalism. Let's wait till Mediawiki flushed all the cashes to see if the template works fine again. Thanks for that --!i! 12:42, 18 January 2012 (UTC)

Not really vandalism, but just a less experimented user that does not know how to categorize templates... The categories he added were breakign the return value of the template that generates the name of a parameter (e.g. fre or frm, if the fr page exists or is missing). This caused that template to generate a paramter name containing a newline and a category between brackets, and that parameter name was then not used at all, and nothing was displayed... Verdy p 13:49, 18 January 2012 (UTC)

No it's realy 'vandalism' as the nick means 'proud and german' and no other edits were made. He added the category even on Pages, that are already categorized --!i! 17:41, 18 January 2012 (UTC)

So the issue is closed. Note that I have added a STRONG warning in comments, on the most problematic template where the edit broke the i18n feature... Verdy p 05:01, 20 January 2012 (UTC)

Changes on Template:Software2

Thanks Verdy, template looks now very clean :) But usually it is welcome to ask before changing so widespread templates (see language template above) --!i! 15:28, 3 January 2012 (UTC)

Yes but where ? Where are so few editors in this wiki in the history ?.

I just apply the general rule "be bold" common on wikis, until there's a problem that sure should be fixed. But without doing this job, the wiki is currently adopting lots of incoherencies that will be harder to fix later, and that will require much more work.

Verdy p 18:30, 3 January 2012 (UTC)

Well, nobody will punish you for that ;) But sometimes you (and I and everybody working in the deep templates) can cause bugs, that argue users and make them feel like "who as that idiot?!?". The history of that page lists a lot of users that have dedicated user talk pages and there is a discussion page on the template itself, that is monitored by the authors (me in this case) of course. The wikiteam is present here and in the forum to assist you upon harder edits. Doesn't matter, don't worry :) --!i! 19:15, 3 January 2012 (UTC)

Too many parser calls

Hi Verdy, the problem with template:languages still persists, so please try to fix the problem that the most pages invoke the parser to often and are now in Category:Pages with too many expensive parser function calls. --!i! 11:06, 15 February 2012 (UTC)

What do you propose ? That I completely remove the tests of existance for minority languages (those that are listed in the unrollable sublist) ?

This would solve the "problem" caused by the visible category (which should be invisible in fact).

Still I think that this template that autodetect available languages should not be used at all.

Anyway, MediaWiki pretends that the test is too expensive, but this is not the case, as it loads and tests the existence of referenced pages as many times when you insert any kind of wikilink within any page: the cost on the database and in the cache of pages, or in memory when rendering an updated page is exactly the same :

All tested pages have exactly the same impact as a static (untested) red link, in terms of performance, as well as in terms of volume in the list of stored references.

Verdy p 11:45, 15 February 2012 (UTC)

I've implemented the solution using Template:LanguageNotTested which uses the same parameters as Template:LanguageExisting : the effect is that those non-tested languages will always appear in the unrollable sublist (of "Other languages") even if they exist (so you'll see some blue links in that second list).

This solves the mjnor problem caused by the category, but absolutely does not affect the number of pages effectively tested by the server, or the performance of its parser.

The top list of tested languages (those that are the most widely populated with translated pages) may be adjusted (see the comment in Template:Languages).

What do you think of this solution ? Verdy p 12:07, 15 February 2012 (UTC)

Note: I've got an idea to allow a page that uses the languages template to force the display of some languages without even having to test for its existence. A single optional parameter, used by "Template:LanguageNotTested" could list those minor languages that you want to force to the first list.

Basically the parameter passed to Template:languages could be "show=br:yi:" and passed again to the Template:LanguageNotTested ; if the latter finds the specific language code (followed by a ":" delimiter) in the value of the show parameter, it will return "{{{1}}}e" instead of always "{{{1}}}m", causing that language to be shown with a static link in the first list, without testing for the existence of the page.

This would minimize the number of pages to edit, because major languages would continue to be tested so that they can be hidden in the second list (if they still don't exist), and only pages created and available in one of the minority languages would have to be specified in the optional "show=" parameter.

What about this idea ?

Note that we could then force all languages (minor or major) to be specified in that show parameter, to remove all #ifexist parserfunction calls, and in that case the Template:LanguageExisting would no longer be used at all ! But this would require a lot of maintenance to update the lists of languages in every page that uses the Template:Languages.

Verdy p 12:27, 15 February 2012 (UTC)

A longer term solution would be to rewrite Mediawiki to eliminate the whole expensive parser call business by using the same logic for #ifexist that it uses for determining whether links are displayed in red. --Andrew 12:42, 15 February 2012 (UTC)

This has already been proposed, the current limit on #ifexist is simply stupid, it does not save anythng and causes more troubles, because in that case the #ifexist parserfunction will always return false after the limit has been reached. This does not save MediaWiki to have to test the existence of pages when displaying links... And there are tons of pages in MediaWiki that display thousands links without any performance problem (most of them are valid and shown in blue, but MediaWiki MUST still perform the test of existence !).

I really don't understand the rationale of this parser limit on #ifexist (except possibly to make sure that a page that attempts to conditionally transclude a lot of subpages with various names, won't transclude too many existing ones, causing severe performance problems in memory/CPU usage when rendering that page ; but the effective limit of the parser should not be there, in #ifexist, but in the maximum number or volume of transclusions, which is already tested separately).

If some Mediawiki users dislike this behaviour it could be a configuration option. Another thought is that it you could loop through all two and three letter abbreviations and have a set of languages that is only limited beyond the ability of the community to translate pages and keep the translations up to date. Andrew 12:55, 16 February 2012 (UTC)

You did not reply to my idea above (about a new "show" parameter). Verdy p 12:47, 15 February 2012 (UTC)

Also, I'd like that you add the effective support for {{int:lang}}, by creating or importing the message ressources in Mediawiki:lang : for each language code imported there, the content of that message should contain exactly the same language code. For example the message Mediawiki:lang/fr should just contain "fr" (but Mediawiki:lang/qqq, assocatd to the private-use language code "qqq" will contain a small documentation about how to translate the Mediawiki:lang message itself).

You can import all the languages codes supported by the Interface of MediaWiki at once, from the "translatewiki.net" project. This won't take a lot of space in the database and it will be extremely stable.

For now, these messages ressources are not preloaded so {{int:lang}} currently returns "⧼lang⧽" (between angle brackets which indicate that there's still no such international message in the "Mediawiki:" namespace with the message name "lang") instead of the code of the language in which all other MediaWiki messages used by the interface are currently displayed on your screen.

With this, we would be able to display the interface directly in the preferred language selecte by the user (in his personnal account if he's logged on), or in the preferred language set in his browser (if he's not connected or has no account).

I cannot do that myself, because the "MediaWiki:" namespace is protected on this wiki (I don't have the admin privilege to edit this namespace, or to translate other messages there, or to import translated and updated messages from "translatewiki.net", or to add additional translatable messages there).

Note that this feature (using int:lang) will work properly only if you have installed this wiki with the option of a per-language cache of wiki pages already parsed by MediaWiki ; if this local cache option is not enabled, the MediaWiki server cache containining this preparsed page will be showing, in "⧼lang⧽", the code of the interface language that was used by the last user that edited the page (or that viewed this page, if this page was not in the server's cache of preparsed pages).

This {{int:lang}} trick, documented and officially supported in the Mediawiki help pages, works in the Wikimedia Commons site and in the Wikimedia Meta site (which are fully internationalisable on the same wiki without using separate per-language wikis), because the "Mediawiki:" namespace already contains all these necessary messages resources in "MediaWiki:lang/*".

Verdy p 14:02, 15 February 2012 (UTC)

Page content language

Is the Mediawiki page content language useful for us? Would it let us write templates that adjust to thwe language of the page, and would it work better for right-to-left languages than the {{Rtl}} template? --Andrew 13:22, 29 February 2012 (UTC)

Yes it is, and it is already activated on this wiki (the ?uselang=xx parameter already works here and allows the MediaWiki UI to be localized accroding to user's preference, this language being also used when writing code with {{int:resource name}} which will autoselect the resource found in [[MediaWiki:resource name/language code]]

But to make it fully functional (where there's a need to translate the UI, not the content of translated pages themselves), without necessarily having to put lots of translations in the "Mediawiki:" namespace (and having them all translated via the translation extension like on translatewiki.net), we should have a way to detect the UI selected by the user to make some templates (or even pages) generating some UI contents specific to some project pages, in the correct language.

For this, I have already asked for the inclusion of the resources normally found in Mediawiki:Lang (and all its subpages, one per language code supported by the MediaWiki UI and for which you have installed the messages in that language) : each subpage just has to contain the language code itself, so for example Mediawiki:Lang/en will only contain "en" (nothing else).

With these very few resources, we don't need administrators privileges to create project pages featuring a translatable UI (separately of the page content language), because we can directly use {{int:lang}} :

• This small code {{int:lang}} currently displays ⧼lang⧽.
• If you have loaded these "Mediawiki:" resources, then this code will display the language code of your current language (selected in your user's preferences, or autodetected by Mediawiki from the browser's settings, if the user is not logged in)
• If you just see "<lang>" within angle brackets instead of your language code, these resources are still missing, and we cannot exploit the full capabilities of templates (with powerful translations like those found in Wikimedia Commons, Wikimedia Meta, and more recently now on most editions of Wikipedia and other projects).

For now, I've built an utility template:langcode whose purpose is in fact different: it will not autodetect the UI language selected by the user, but the language used on the translated pages, by detecting the language code prefixes if possible (the result will be static and will not depend on user's settings).

— Verdy_p ^(talk) 02:56, 2 March 2012 (UTC)

Clean-up

Tu créés des tonnes de redirections inutiles (comme [[1]]) alors qu'il faudrait faire un vrai travail de nettoyage. Si tu changes le titre d'une page, met à jour les liens vers cette page plutot que de faire une redirection. Si tu veux supprimer une page, ajoute le template {{d}} plutot que de rediriger vers la page d'origine. Tu ajoutes aussi des liens vides inutiles (comme ici FR:Road signs in France). --Pieren 09:04, 2 March 2012 (UTC)

Non ces liens sont utiles le temps de créer les pages (car sinon on a des liens rouges).... ce que je fais... — Verdy_p ^(talk) 09:05, 2 March 2012 (UTC)

Et justement je fais le nettoyage des liens résiduels au passage, et je vérifie déjà tout ce que tu m'indiques. — Verdy_p ^(talk) 09:06, 2 March 2012 (UTC)

Les liens vers des pages vides sont inutiles. Créé d'abord la page puis ajoute le lien ensuite. De plus, personne ne comprend ton changement de casse du namespace FR (que je suis en train d'annuler sur certaines pages). Je ne suis pas contre le changement mais il faut le faire en concertation avec les autres auteurs, les autres pays et sur tout le wiki de manière cohérente. Pour l'instant, on a l'impression que tu décides et travaille seul, ce qui n'est pas une wiki attitude. Sais-tu seulement que le FR est un namespace et non un language ni un pays ? --Pieren 09:32, 2 March 2012 (UTC)

Bien sûr que je le sais (et mes commentaires en tiennent compte justement ! cela concerne actuellement ES, FR, IT, JA, NL, RU, etx). En plus je ne l'ai pas fait sans en parler? J'ai laissé du temps pour qu'on me réponde. Je ne me suis pas précipité, mais il faut continuer puisque cela n'avance pas depuis des mois et que la situation ne cesse d'empirer. C'est la façon de faire dite "Just do it", très wiki au contraire, et que j'explique aussi dans les commentaires. — Verdy_p ^(talk) 09:50, 2 March 2012 (UTC)

Pourquoi ? C'est très simple au contraire : tout en minuscule, cela ne nécessite nullement de changer la casse des namespaces (même si on peut le faire car les namespaces ne sont pas sensibles à la casse). C'est bien plus simple à gérer comme ça : on écrit les préfixes toujours de la même façon, cela ne change strictement rien aux liens eux mêmes. — Verdy_p ^(talk) 09:34, 2 March 2012 (UTC)

C'est encore plus simple de laisser le namespace en majuscule partout et de créer des titres en Français avec redirection comme tu l'avais suggérer sur la ML. Pourquoi altérer tous les liens si c'est pour recommencer plus-tard ? --Pieren 09:37, 2 March 2012 (UTC)

La suggestion de la ML tient encore, elle porte que des titres localisés par une redirection du nom anglais vers le nom dans une autre langue, pas sur les préfixes qui doivent être utilisés partout de façon uniforme pour faire fonctionner les liens interlangues. Correctement. — Verdy_p ^(talk) 09:52, 2 March 2012 (UTC)

D'ailleurs ce n'est pas un travail inutile d'unifier tout ça, car c'est la situation actuelle à laquelle personne ne comprend rien car ça change selon les langues, selon les pages, et selon les espaces !!! On se retrouve alors avec des pages en doublon à fusionner où l'une est plus à jour que l'autre ou bien une n'est pas trouvée alors qu'elle existe.

Et j'en ai vu beaucoup que je récupère au fur et à mesure, et reconnecte au fur et à mesure. Donc merci de ne pas dénigrer ce que je fais, car sans ce travail c'était déjà le bordel intégral, un bordel qui ne faisait qu'empirer et que je suis bel et bien en train de nettoyer.

Je n'ai pas changé les majuscules des namespaces, ce n'est pas nécessaire (même si ce serait logique qu'ils soient aussi tout en minuscules par défaut: c'est la recommandation officielle pour BCP 47, et ça évite les confusions avec les codes de régions et pays qui se mettent conventionnellement en majuscules : "ja" pour japonais, "JP" pour Japon). Pour les liens en revanche on ne se pose pas la question selon les langues, on met tout en minuscule et ça marche tout de suite partout ! — Verdy_p ^(talk) 09:40, 2 March 2012 (UTC)

Relis mon post. Le changement de casse du namepace dans un lien est inutile. En plus, tout mettre en minuscule suggère que les pages sont pour tous les francophones, ce qui n'est pas vrai. Je ne nie pas qu'un nettoyage soit nécessaire mais pour l'instant, 98% de tes éditions sont contre-productives. --Pieren 10:02, 2 March 2012 (UTC)

Si c'est pour la France, on met le mot France dans le titre en Français ou en anglais (Frankreich dans un titre traduit en allemand). (par exemple 'WikiProject France' ou 'Roads in France'. Le préfixe désigne toujours les langues, pas les pays. Même les pages sur les pays peuvent être traduites, les liens interlangue ne mentionnent nulle par les pays par le préfixe, tu devrais l'avoir compris depuis longtemps... — Verdy_p ^(talk) 10:09, 2 March 2012 (UTC)

Oui. Merci de m'expliquer les titres de pages dont je suis souvent l'auteur original. Le préfixe n'est pas la langue mais le namespace, c'est là oú tu te trompes. On peut changer ça mais alors il faut le faire en concertation avec les autres utilisateurs de namespace comme le 'DE'. L'exemple 'WikiProject France' que tu cites est un mauvais exemple puisque la page est antérieure à la création des namespaces dans le wiki et on ne va pas mettre 'France' dans tous les titres de pages qui ne concernent que la France. Comme pour les tags, les prefixes peuvent soit indiquer un pays, soit une langue, il n'y a pas de norme sur ce point (la seule convention étant la casse pour indiquer si c'est le pays ou la langue). Résultat, certains titres seront en 'FR:' et d'autres en 'fr:' (on peut même imaginer la combinaison FR:fr), ce qui ne va pas dans le sens de la simplification dont tu parles. Mais encore une fois, au risque de me répéter, il faut travailler de concert avec les autres pays et ne pas adopter nos propres conventions sur le wiki --Pieren 10:34, 2 March 2012 (UTC)

Je n'ai rien inventé, bon nombre de modèles existants ne prennent les préfixes (que ce soit dans des namespaces dédiés pour les articles principaux de quelques langues ou non) que comme des codes langues. Ils ne peuvent pas faire de classification par pays. Si des namespaces dédiés ont été créés, c'est pour faciliter les recherches dans l'index selon les termes utilisés et limiter alors les synonymes trouvés. Ces recherches permettent alors de filtrer la langue.

Les namespaces ont alors pour intérêt principal de faire ce tri, mais ne sont créés que pour les langues qui ont suffisamment de contenus, la plupart n'ayant pas de namespace dédié. J'avais bien compris ça. La présence du namespace dédié ne change rien à la signification des noms d'articles, c'est juste une facilité.

C'est bien pour ça que le préfixe pour le japonais est "JA" (code langue) et non "JP" (code pays), qu'il n'y a pas de préfixe séparé pour le Royaume-Uni et les USA (pas de préfixe, mais occasionnelement "en:" quand la page initiale a été traduite d'une autre langue que l'anglais, "en" désignant l'anglais et non pas la seule Angleterre qui n'est pas le Royaume-Uni, sinon on aurait eu depuis très longtemp un préfixe "UK" ou "GB"), ni non plus pour le Portugal ou le Brésil. Ni non plus pour la France et la Belgique (qui utilise des pages soit dans FR, soit dans NL, voire dans DE), ou la Suisse...

Tu sembles croire que ce sont des préfixes de pays, cela ne l'a jamais été jusqu'à preuve du contraire ! — Verdy_p ^(talk) 10:47, 2 March 2012 (UTC)

Non. Relis mes posts. Je dis que le préfixe est jusqu'à maintenant un namespace et pas une langue ou un pays. Mais toi, tu veux le transformer en préfixe de langue bien que ce soit en majuscule. Encore une fois, au risque de me répéter, on peut envisager le changement de casse du prefixe mais il faudrait le faire en accord avec les autres communautés de langues sur ce wiki. --Pieren 11:40, 2 March 2012 (UTC)

J'ai bien compris que c'est un namespace, et j'avais parfaitement lu. Visiblement tu n'as pas lu pourquoi les namespaces ont été créés (faire des recherches ciblées), alors que c'est documenté. Ils se créent au fur et à mesure des traductions pour les sortir de l'espace principal où on trouve les pages anglaises.

Il se trouve que je participais déjà à ce wiki à l'époque de la création des namespaces. Je sais donc parfaitement pourquoi ils ont été créés. --Pieren 12:13, 2 March 2012 (UTC)

Qu'ils soient nommés en majuscules ou minuscules n'a pas d'importance en fait car la casse des namespaces n'est pas significative du tout dans les liens (ce que tu ignores visiblement !), cela influe uniquement sur le titre affiché en haut des pages.

Je le sais aussi mais faire des liens "fr:Contact" qui tombent ensuite sur une page "FR:Contact" n'est pas très élégant. --Pieren 12:13, 2 March 2012 (UTC)

Pas élégant en quoi ? Les liens ne sont pas affichés, quand ils sont dans des tooltips de toute façon ils sont mal renseignés pour être utile (on devrait avoir un vrai "title" décrivant le contenu de la cible du lien). L'URL n'est pas lisible non plus et souvent masquée pour plein d'utilisateurs ou dans des navigateurs qui n'affichent que le nom de domaine (le reste étant tronqué). Il reste quoi alors ? Le texte à afficher dans la page, pour lequel c'est inutile d'afficher même ce préfixe.

Si réellement on affiche ce préfixe, les gens sont plus habitués à le voir en minuscules dans les liens interwikis de Wikipédia...

Pour l'instant je n'ai même pas proposé de changer la casse de ces namespaces (mais d'autres l'ont déjà fait sans expliquer pourquoi ni insister...).

Je milite tout de même pour une simlification des règles de création de page : tout mettre en minuscules est compréhensible par tout le monde, quoi que le wiki affiche ensuite. Ça évite des erreurs pour les langues qui n'ont pas (pas encore) d'espace de noms dédié, et qu'on n'aura pas besoin non plus de renommer ensuite si ce changement survient. Ça homogénéise le comportement avec Wikipédia, ça facilite les échanges et créations de liens croisés...

Car il y a encore plein de pages dans diverse langues qui se plantent pour savoir quand on peut mettre en majuscules, alors que personne ne se tromperait si on disait que tous ces préfixes (de namespace ou non) peut être écrits (et générés) en minuscule (et sans perte de performance à cause des redirections, puisqu'il n'y a plus besoin de ces redirections sur le serveur) — Verdy_p ^(talk) 12:33, 2 March 2012 (UTC)

En revanche si une page n'a pas de namespace dédié, le préfixe de langue (oui! de langue, le préfixe ici est sur 2 lettres, que ce soit celui d'un namespace ou non !) utilisé dans le nom aura sa casse significative au delà de sa première lettre (seule la première lettre a une casse non significative dans ce cas). — Verdy_p ^(talk) 11:48, 2 March 2012 (UTC)

Bonjour

Je voie que tu as supprimé de la page d’accueil la boîte "Boîte à outils du cartographe" que j'avais ajoutée, pour reléguer les liens correspondants en bas de page, et de manière peu visible. J'avais pourtant essayé de faire à la fois discret (pour ne pas surcharger la page d’accueil) et efficace (retrouver rapidement l'information pertinente). Je conçois très bien que tu ne sois pas d'accord avec ce que j'avais fait, mais il est indispensable de pouvoir TRÈS facilement trouver ces guides. Peut-être connais-tu tous les tags par cœur, ce n'est pas mon cas, et rendre ces liens peu visible risque de décourager certaines bonnes volontés. Balaitous 22:53, 9 June 2012 (BST)

Je n'ai RIEN enlevé, TOUT y est. J'avais retrié un peu et m'étais arrongé pour que les styles comparables s'alignent correctement entre les deux colonnes. Les outils sont donc tous là, dans chaque section appropriée en en vis-à-vis. Note qu'il y avait DEUX sections de boites à outils, il n'y en a plus qu'une seule qui contient le tout. — Verdy_p ^(talk) 23:03, 9 June 2012 (BST)

Tag:boundary=political

Salut ! A propos des limites "political", tu as mis comme commentaire dans euro_const (European Constituency) que c'était peut-être le territoire de l'Union mais en fait je crois qu'il s'agit plutôt des circonscriptions électorales des députés européens. (Circonscriptions législatives européennes, cf. w:European Parliament constituency). Je me permets donc de le corriger, si tu n'y vois pas d'inconvénient. Damouns 15:22, 15 October 2012 (BST)

Je veux bien mais ce n'est documenté nulle part et jusqu'à présent je n'ai même pas vu un seul exemple où c'est utilisé. Pour moi "constituency" en anglais signifie en gros ce qu'on désigne en français comme "entité composante" (ou membre). Comme les composantes de l'UE sont les pays membres dans les territoires qu'ils incluent dans l'Union, cela me semble être la meilleure explication.

Sinon l'expression anglais traduirait effectivement "circonscription européenne" ("European circonscription" et non "European constituency") et le tag est alors très mal défini, mal utilisé, ou mal nommé !

Note bien qu'avant ce commentaire, j'avais mis que c'était mal documenté (depuis longtemps déjà et jamais rectifié depuis pour l'expliquer).

On a une vraie utilité à cartographier le territoire de l'UE, qui n'est PAS la somme des territoires entiers des pays membres (comme je l'ai mis dans le commentaire).

— Verdy_p ^(talk) 16:05, 15 October 2012 (BST)

En plus tu te trompes dans ton commentaire : tu oublies les Pays-Bas (le Royaume est divisé en 3 États, seul celui des Pays-Bas stricto sensu est dans l'UE).

Quant à la France, des territoires sont hors de l'Union Européenne mais ne constituent PAS des entités séparées (voire même n'ont absolument aucune autonomie pusiqu'ils sont gérés directement par le gouvernement de la République.

Tu oublies aussi le Danemark (les Îles Féroé et le Groenland ne sont pas pas l'UE).

Si tu parles des circonscriptions électorales européennes, c'est tout aussi faux !

Bref ton commentaire modifié ne documente strictement rien de mieux et revient même en arrière : cela redevient encore plus ambigu !

Note: la totalité des électeurs de tous les territoires nationaux des pays membres sont électeurs européens, même quand leur territoire local n'est pas dans celui ce l'UE, ou est exclu de l'application du droit européen (par exemple l'entité de Chypre du Nord). De fait l'union des circonscriptions législatives européennes est bien l'union de la totalité des territoires des pays membres (mais ils ne peuvent pas former de circonscription électorale européenne pour eux-mêmes, ils sont nécessairement associés dans une circonscription qui inclue une partie placée dans le territoire de l'Union : le Groenland vote mais depuis qu'il ne fait plus partie de l'UE, sa circonscription électorale a du être fusionnée avec celle du Danemark métropolitain).

Note que cela reste vrai aussi pour le Royaume-Uni, car ses territoires d'outre-mer, les possessions britanniques et les possessions de la Couronne (Jersey, Guernesey et Man) ne font pas formellement partie du Royaume-Uni, bien que leurs électeurs aient la citoyenneté britannique et élisent leurs représentants au parlement britannique (en plus de leur parlement local), les lois britanniques ne s'appliquant à ces territoires que quand elles sont approuvées par leur parlement local qui peut s'y opposer ou les modifier (en les approuvant assez souvent, ils peuvent appliquer une grande partie de la législation de l'Union européenne comme le Royaume-Uni, mais ils n'y sont pas obligés par les traités de l'Union et ils ont leur propre compétence judiciaire) ; mais ils disposent de leur propre passeport s'ils ne sont pas natifs du Royaume-Uni (les lois britanniques et la législation européenne s'applique en revanche aux citoyens britanniques natifs du Royaume-Uni ou qui ont opté pour sa nationalité au lieu de la nationalité de leur territoire)...

Ce que je ne sais pas en revanche c'est si les électeurs de Gibraltar (dont le territoire a été intégré par le Royaume-Uni à leur demande, dans celui de l'Union européenne pour entrer dans son union douanière en même temps que l'Espagne voisine) votent à ces élections européennes (théoriquement non puisqu'ils ne sont pas au Royaume-Uni et ne sont don pas membres...) et je me demande alors dans laquelle des circonscriptions législatives européennes mises en place par le Royaume-Uni : celle de Londres ? Sinon les bases de souveraineté britanniques à Chypre (qui sont également hors du Royaume-Uni) semblent voter pour les élections européennes avec ceux de Chypre (en effet bon nombre de résidents dans ces bases ont la nationalité chypriote) pour les natifs du lieu, ou sinon avec leur région d'origine au Royaume-Uni quand ils en ont la nationalité.

— Verdy_p ^(talk) 16:11, 15 October 2012 (BST)

J'ai modifié la ligne du tableau pour renvoyer à l'article complet, si tu crains que ma modification n'ait rendu les choses ambiguës. À propos, dans Wikipedia il est précisé que Gibraltar vote et fait partie de la circonscription du Sud-Ouest de l'Angleterre (voir cet article). Bon mapping ! Damouns 15:20, 30 October 2012 (UTC)