User talk:Kontributor 2K

Bonjour !
Kontributor 2K (d) 08:58, 28 March 2022 (UTC)[reply]

File:Blason famille Advisart.svg has been listed at Commons:Deletion requests so that the community can discuss whether it should be kept or not. We would appreciate it if you could go to voice your opinion about this at its entry. If you created this file, please note that the fact that it has been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues. Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you! Afrikaans ∙ Bahasa Indonesia ∙ Bahasa Melayu ∙ bosanski ∙ català ∙ čeština ∙ dansk ∙ Deutsch ∙ Deutsch (Sie-Form)‎ ∙ eesti ∙ English ∙ español ∙ Esperanto ∙ français ∙ galego ∙ hrvatski ∙ íslenska ∙ italiano ∙ magyar ∙ Nederlands ∙ norsk bokmål ∙ norsk nynorsk ∙ occitan ∙ Plattdüütsch ∙ polski ∙ português ∙ português do Brasil ∙ română ∙ shqip ∙ sicilianu ∙ slovenčina ∙ slovenščina ∙ suomi ∙ svenska ∙ Tiếng Việt ∙ Türkçe ∙ Zazaki ∙ Ελληνικά ∙ беларуская ∙ беларуская (тарашкевіца)‎ ∙ български ∙ македонски ∙ русский ∙ српски / srpski ∙ українська ∙ հայերեն ∙ বাংলা ∙ മലയാളം ∙ ပအိုဝ်ႏဘာႏသာႏ ∙ မြန်မာဘာသာ ∙ ไทย ∙ 조선말 ∙ 한국어 ∙ 日本語 ∙ 简体中文‎ ∙ 繁體中文‎ ∙ עברית ∙ العربية ∙ پښتو ∙ فارسی ∙ ދިވެހިބަސް ∙ +/−

-sche (talk) 20:26, 9 August 2023 (UTC)[reply]

File:Dampierre.svg has been listed at Commons:Deletion requests so that the community can discuss whether it should be kept or not. We would appreciate it if you could go to voice your opinion about this at its entry. If you created this file, please note that the fact that it has been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues. Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you! Afrikaans ∙ Bahasa Indonesia ∙ Bahasa Melayu ∙ bosanski ∙ català ∙ čeština ∙ dansk ∙ Deutsch ∙ Deutsch (Sie-Form)‎ ∙ eesti ∙ English ∙ español ∙ Esperanto ∙ français ∙ galego ∙ hrvatski ∙ íslenska ∙ italiano ∙ magyar ∙ Nederlands ∙ norsk bokmål ∙ norsk nynorsk ∙ occitan ∙ Plattdüütsch ∙ polski ∙ português ∙ português do Brasil ∙ română ∙ shqip ∙ sicilianu ∙ slovenčina ∙ slovenščina ∙ suomi ∙ svenska ∙ Tiếng Việt ∙ Türkçe ∙ Zazaki ∙ Ελληνικά ∙ беларуская ∙ беларуская (тарашкевіца)‎ ∙ български ∙ македонски ∙ русский ∙ српски / srpski ∙ українська ∙ հայերեն ∙ বাংলা ∙ മലയാളം ∙ ပအိုဝ်ႏဘာႏသာႏ ∙ မြန်မာဘာသာ ∙ ไทย ∙ 조선말 ∙ 한국어 ∙ 日本語 ∙ 简体中文‎ ∙ 繁體中文‎ ∙ עברית ∙ العربية ∙ پښتو ∙ فارسی ∙ ދިވެހިބަސް ∙ +/−

-sche (talk) 20:26, 9 August 2023 (UTC)[reply]

I've no idea why you have done this, but "in chevron" doesn't refer to any actual chevron in the shield, it means the charges are disposed in chevron, which is a common way of disposing them see here, for instance. Can you explain your actions there, removing the category from the coats of arms and then redirecting to some unrelated thing? Darwin ^Ahoy! 14:18, 13 January 2024 (UTC)[reply]

Hi Darwin,

Actually "in chevron" refers to "disposed 1 & 2" (one in top, two at bottom, as "triangle"), that's why I eventually redirected to the corresponding category "one and two". Also the category "Chevrons in heraldry" refers to the chevron element, not to elements disposed in chevron.

"2 & 1" is actually like "reversed chevron", not "chevron", and is the default position for 3 elements : no specific category is needed for these at all.

Notifying @Jpgibert: for further support if needed.

Regards, --Kontributor 2K 14:25, 13 January 2024 (UTC)[reply]

Hello. That's not how it appears in Portuguese heraldry, here it it's said the charges are disposed "em aspa", which is literally "in chevron". And even if "in chevron" is the most common arrangement for 3 charges, a category with that name (or an equivalent version) would be in place to distinguish those from the ones whit non standard charge arrangements. Darwin ^Ahoy! 17:07, 13 January 2024 (UTC)[reply]

Well,

We should wait for advices from @Jpgibert: , @Ssire: and also @Chatsam: , who are referents of the french Blazon project and know about european heraldry too.

In any case, i'm not sure that creating a category "in-chevron" to designate elements in a "reversed-chevron position" (2 in chief, 1 in bottom) to comply with portuguese heraldry is truly relevant in here, where categories are in english. Obviously, this file, for an example, is truly not "3 fleurs-de-lis in chevron".

Moreover, making a specific category for elements "2 & 1", would imply doing so for all heraldic elements by 3, not only fleurs-de-lis, which means it should be strongly discussed before action

You're welcome there on the project tp, unless you know a better place to discuss this point,

--Kontributor 2K 17:33, 13 January 2024 (UTC)[reply]

Hi, your revert mentions ""Surrounding folder already categorized in Category:Maps showing 11th-century history" --> but I categorized the maps as "Maps of 11th-century Europe". That is a difference, both categories are child-nodes of the 11th-century parent category. --Enyavar (talk) 22:41, 7 March 2024 (UTC)[reply]

Hi Enyavar

You're welcome

Actually it's already a mess, maybe the folder "Maps of the First Crusade" should be moved to "Maps of 11th-century Europe" directly instead of its content

Regards, --Kontributor 2K 22:57, 7 March 2024 (UTC)[reply]

Better not: most maps of the Crusades don't show a lot of Europe, as the fighting happened mostly in Asia. Best, --Enyavar (talk) 22:57, 7 March 2024 (UTC)[reply]

As you can see, "Maps of the First Crusade" is already categorized in simlar categories (Maps of the Kingdom of Jerusalem, Maps of the Byzantine empire in the 11th century, Maps of the history of the Middle East)

I mean it's already a mess… --Kontributor 2K 23:01, 7 March 2024 (UTC)[reply]

True, most of these categories don't apply to each and every map in the category.

But again: There are maps of the First Crusade, there are maps of Europe in the same time, and a map that shows both elements at once, may get both categories.

By the way, I can't understand why you removed "French-language maps" from this one. I would rather move it to "French-language maps showing history of Europe"! Any map deserves to be categorized by its language (...although sadly, most aren't). Best, --Enyavar (talk) 23:50, 7 March 2024 (UTC)[reply]

Indeed, not every crusade map shows Europe, I have reverted my reverts.

About the language category I removed, I found it was too vague, and I didn't know about the one you mention, to which I eventually added the series' other maps.

Regards, --Kontributor 2K 10:24, 5 March 2024 (UTC)[reply]

Hello,

I see we might be working at cross-purposes here. I am trying to move the specific examples of "Azure 1 lion rampant or" from the general very broad cat Category:Azure a lion or (which could include lions passant, lions reguardant, etc) to a more definite category Category:Azure 1 lion rampant or. Does that make sense?Lobsterthermidor (talk) 08:35, 3 May 2024 (UTC)[reply]

Hi Lobsterthermidor,

Welcome here.

Actually 'Azure a lion or' means 'a (single) lion rampant or on an azure field'…

Lions-guardant and lions-passant are different figures than the 'lion' itself (which is always rampant)

Lions-rampant and lions-guardant (léopard) should not be sub-categories of 'lion'… attitudes make the figure totally different, a fully other one…

Don't you think ?

Kontributor 2K (talk) 08:45, 3 May 2024 (UTC)[reply]

Edit : Pinging @Jpgibert: who might join the conversation (at least I hope so)

Thanks, I think Azure a lion or can mean any form of heraldic lion, not just a lion rampant. The usual full blason for that would be Azure a lion rampant or. Thus the blazon Azure a lion or is very broad and vague, as it can include Azure a lion passant or, Azure a lion passant guardant or, or any of the dozen or so forms of golden lion on a blue field. As far as I know (certainly in English heraldry, and I think French heraldry is the same) Azure a lion or does not signify a lion rampant. That might be a reasonable guess if one were to interpret it, but it's very vague. I have never seen that in an official blason, the form of lion is always specified. I am trying to categorise these lions from the broad category to a more specific category, which gives the attitude of the lion. I hope that makes sense.Lobsterthermidor (talk) 09:03, 3 May 2024 (UTC)[reply]

PS: I am confused as to why you state that "Lions-guardant and lions-passant are different figures than the 'lion' itself (which is always rampant)". How can a lion passant "always be rampant"? Maybe if we can clarify that we can understand each other better. You can write in French if you wish, perhaps you can express more precisely what you mean? Thanks.Lobsterthermidor (talk) 09:03, 3 May 2024 (UTC)[reply]

'A lion' means 'a lion rampant'

'A lion passant' is a different figure

'A lion guardant' means 'a leopard'

'Azure a lion or' means 'a (single) lion rampant or on an azure field', it can neither be an enclosing category for 'Azure a lion passant or' nor for 'Azure a lion passant or'…

@Jpgibert: also deals with british heraldry and could help us

Il peut nous aider à démêler la situation

Et aussi d'autres cas à problèmes concernant les catégories

Kontributor 2K (talk) 09:15, 3 May 2024 (UTC)[reply]

Hello Lobsterthermidor,

Just to clarify the Kontributor 2K explanation, in french heraldry, the blazon Azure a lion or is strictly equivalent to Azure a lion rampant or. In french blazon, lion is always rampant by defaut this is why, we never use rampant in blazon for this particular attitude of the lion. Jpgibert (talk) 09:16, 3 May 2024 (UTC)[reply]

The problem is Commons. The categories are relative to the english heraldry, not french, german, spanish, italian... heraldry. So, it is not possible to create a category structure able to take in account all possibilities.

For me, the lion is a real problem to be correctly categorized, and, I think, it is important to use clearly the attitude in the category and produce lion rampant, lion guardant, lion regardant, lion sejant, etc.

If I correctly understand your point of view Lobsterthermidor, the Azure a lion or can be a super-category of the Azure a lion rampant or or Azure 1 lion rampant or (I prefer the first form).

But, maybe it is interrested to by more precise and use as super-category: Azure a lion or by attitude.

Jpgibert (talk) 09:23, 3 May 2024 (UTC)[reply]

Thanks, very interesting. This is a big difference between English and French heraldry! In English heraldry we always specify "rampant" - or whatever the attitude is, passant, passant-guardant, etc. So this is the source of the misunderstanding here. Nor in English heraldry does a "leopard" signify a lion guardant! Oh dear! In English heraldry a "leopard" is actually an old-fashioned term for a lion passant guardant, as in the royal arms of Plantagenet, sometimed blazoned as "three leopards" ("the Leopards of England"). Shakespearian! But that is now rather obsolete and quaint. You will not find the term "leopard" in modern English heraldry. So what is the solution?

Different nations have different laws and customs concerning heraldry. This is English (language) Wikipedia, American really, but as to the rules of American heraldry I don't know, I don't think there are any. In general here we seem to follow the rules of English heraldry in terminology and practice. I know that's really annoying to non-English people and I understand entirely! I think therefore that as in English heraldry the attitude of the lion is always specified in the blason, we should follow that principle. In English heraldry the category "A lion" is very vague and broad, yet in French heraldry as you say it is specific. Do we now understand each other as to what the confusion was? If so, can we therefore please agree to follow rules of English usage in using the term "lion rampant" rather than "lion", to avoid major confusion? Lobsterthermidor (talk) 09:45, 3 May 2024 (UTC)[reply]

Sorry, I meant 'lion passant guardant', not 'lion guardant'…

I eventualy agree, especially with Jpgibert about the super-category 'Azure a lion or by attitude', which would imply the de deletion of the 'Azure a lion or' category and a lot of other works

Isn't that the good point ?

Kontributor 2K (talk) 09:55, 3 May 2024 (UTC)[reply]

Thank you Jpgibert & Kontributor 2K, I think we are reaching an understanding of the two positions. This is actually quite an interesting discussion and I have learned something more about French heraldry. The reason I feel it's best to use a numeral, for example Azure 1 lion rampant or rather than Azure a lion rampant or, is that we have categories for "2 lions", "3 lions", etc, so "1 lion" matches better than "a lion". It's more logical and scientific. I know we don't use numerals in blasons in either English or French heraldry, but we use numerals for categorisation here, for example "3 lozenges in heraldry". So yes, can we use a super-category Azure 1 lion or, to contain sub-categories Azure 1 lion rampant or, Azure 1 lion passant or, Azure 1 lion passant guardant or, etc? In which case the super-category Azure 1 lion or (being a very broad category - in English usage) should have no images in it, only sub-cats. Does that make sense?Lobsterthermidor (talk) 10:02, 3 May 2024 (UTC)[reply]

Kontributor 2K, sorry I missed your last comment, can we have a super-category "Azure 1 lion or by attitude" (using numeral "1"), rather than "Azure a lion or by attitude"? That matches better with categories "2 lions", "3 lions", etc. "Azure 1 lion or by attitude" will then contain sub-categories "Azure 1 lion rampant or", "Azure 1 lion passant or", etc. Yes, eventually (let's not rush it!) the present category 'Azure a lion or' would be deleted, when all images have been transferred to "Azure 1 lion rampant or". At present I wish to continue transferring images from 'Azure a lion or' to "Azure 1 lion rampant or". Would that be OK?Lobsterthermidor (talk) 10:10, 3 May 2024 (UTC)[reply]

'Azure 1 lion or by attitude' sounds good & OK.

The other problem is that 'Azure 1 lion rampant or', for an example, refers here to the field's color + the lion as the main item ; example : this file is not 'Azure a 1 lion rampant or' but : 'Azure a bend or' + '1 lion rampant or', thus it should not be categorized in 'Azure 1 lion rampant or' but : 'Azure a bend or' + '1 lion rampant or in chief' or so…

Jpgibert, Lobsterthermidor, what do you think ?

Kontributor 2K (talk) 10:17, 3 May 2024 (UTC)[reply]

K2, I see what you mean, but possibly we don't want to fragment into too many categories where there may be only 2 or 3 members. When a category gets huge, then it needs a re-think as to how to sub-categorise. I intend to move these 545 images today, so that will result in quite a large cat "Azure 1 lion rampant or". When we get there, maybe let's then see whether we want to split-out further. For example if there are 5 or 10 images of lions with bends, as in your image, then perhaps let's create a new cat for them. It's too early to tell at present if it's really needed. It can get quite complex and confusing if too much is done at one time, I find. I'm trying to go one step at a time, nice and slowly.Lobsterthermidor (talk) 10:36, 3 May 2024 (UTC)[reply]

In this case, the example image could just be categorized in 'Azure a bend or' + '1 lion rampant or armed langued gules'…

Moreover, bends' color, or other-pieces-containing-a-lion-[or]-anything's color, should not be considered as the field's color… meaning a lion rampant or on a bend gules should not be categorized in the 'gules 1 lion rampant or' category at any time…

I think

Kontributor 2K (talk) 10:50, 3 May 2024 (UTC)[reply]

The colour the lion is "sitting on" is the colour of the field for the purpose of categorising the lion. For example, if a lion rampant or is on a "canton gules", it should go prima facie in "Gules 1 lion rampant or". If it is on a chief gules, it should also should go in "Gules 1 lion rampant or". If it is on a bend gules it should also go in "Gules 1 lion rampant or". If there are lots of lions rampant or on bends gules, yes, then let's have a separarate category. But I don't think it's useful to have cats with just 1 or 2 members, in fact it's very confusing and unhelpful to the user. Your image belongs in 2 cats: Azure a bend or and Azure 1 lion rampant or. If it turns out there are 10 similar images, then I agree, new cat is needed. But not at the moment I would suggest. Else we could create dozens and dozens of sub-cats with 1 or 2 members, which would be a nightmare. Let's see what we get when all 545 images have been transferred, and then do another exercise, one step at a time (it gets confusing!) and group 10 similar images into new cats then, I would suggest.Lobsterthermidor (talk) 11:11, 3 May 2024 (UTC)[reply]

I’m not going to edit war over something petty: is the “5 in heraldry” category exclusively for five charges or can it refer to the concept of five in general? And if it’s the former where are things related to 5 that aren’t groups of charges supposed to go, without creating a redundant and confusing secondary category? Dronebogus (talk) 10:50, 19 June 2024 (UTC)[reply]

Hi Dronebogus, & welcome,

For sure, the categories in Category:Stars by number of rays, should be unified.

The number refers to the number charges, and might as well refer to the number of rays in a star, eventually

Also, I noticed that "Category:Groups of" , is not specific t heraldry…

+ Kontributor 2K (talk) 11:05, 19 June 2024 (UTC)[reply]

“Eventually”? Dronebogus (talk) 04:26, 20 June 2024 (UTC)[reply]

Yes,

Also, the Sun might be catgorized in 'Category:16 in heraldry' & 'Groups of 16', or 12; one should not forget Mullets pierced which group 5 or 6 rays; there are also Quatrefoils, Cinquefoils etc.

After all

Kontributor 2K (talk) 08:30, 20 June 2024 (UTC)[reply]

Bonjour, Suite à nos échanges sur les Roquefeuil, j'ai regardé quelques fichiers que j'avais crée. J'ai remarqué quelques corrections mineures, qui parfois entrainent l'affichage d'un code wc3 invalide, la suppression de la provenance d'Inskape et autres anomalies. En prenant pour exemple le fichier Tournemire.svg créé sous licence le 6 février 2010, vous le remplacer(Superseded) par une copie dont vous vous attribuer la paternité le 11 aout 2022. C'est une violation de licence. Si vous souhaiter intervenir sur le nom, rien de plus simple, il y a une option "renommer" ... ainsi vous conserver un historique du fichier Je vous serai gré de corriger, et de "rendre à César ce qui est à César", étant de nature conciliante, je ne tiens pas à poster un message sur le bulletin des administrateurs. Bien cordialement Zardoz91 (talk) 01:21, 10 July 2024 (UTC)[reply]

Bonjour Zardoz91,

Je ne vois pas bien ce que vous voulez dire,

Le fichier File:Blason famille fr de Tournemire.svg ne contient aucun élément du fichier File:Tournemire.svg.

Il est totalement différent : la bordure n'est pas de la même épaisseur, l'espacement des beasants n'a pas la même régularité, celui des mouchetures non plus, les bandes sont un peu moins larges et inclinées à 45° exactement, entre autres

Il utilise un élément sous licence cc03 (moucheture) et est lui-même publié sous licence cc04 (compatible).

Le fichier File:Tournemire.svg contient bien, par ailleurs, 2 erreurs w3c. Il est désormais affiché qu'il n'en contient pas : c'est une nouvelle erreur.

Cordialement, Kontributor 2K 09:06, 10 July 2024 (UTC)[reply]

J'ajoute que sur ce même fichier, les besants ne sont pas centrés à l'identique horizontalement à droite et à gauche, ce qui pose un problème de symétrie. Les 2 et 3 en chef ne sont pas centrés à l'identique verticalement, et l'espace entre les deux est trop important, créant un vide en plein mileu de cette partie de la bordure ; de plus ils forment un ensemble qui n'est pas centré horizontalement. Le 1er, par ailleurs, est plus haut que le 4e.

Il y a un espace inutilisé en haut du fichier, et la bordure de l'écu, à gauche, remonte plus haut qu'à droite (il faut zoomer).

Toujours en zoomant, on constate que le coin supérieur gauche du canton a un problème, et que le bloc contenant le fond jaune et les bandes est décalé vers la droite, débordant des contours de l'écu central, les deux premières bandes, quant à elles, débordant de l'écu principal. Toujours à droite.

Si la troisème bande, pour sa part, déborde en haut à gauche de l'écu, au niveau du 2nd besant (verticalement), ça a l'avantage de ne pas se voir.

Quant aux métadonnées qui sont sans rapport avec le fichier, le problème est surtout que celles-ci sont loin d'être une exception (dans la foule des blasons).

Kontributor 2K 09:36, 10 July 2024 (UTC)[reply]

Quant à celui-ci : File:Meymont.svg, que vous avez rétabli dans une ancienne version : c'est bien, mais que fait-on d'un modèle asymétrique dans un armorial ?? (encyclopédiquement parlant)

Kontributor 2K 10:28, 10 July 2024 (UTC)[reply]

Bonjour,

Actuellement, je suis actif sur les fichiers que j'avais importés, pour corriger leurs anomalies. Effectivement, je suis souvent tombé sur vos modifications. Loin de moi, la volonté d'engager une guerre d'édition, ce que je ne ferai sous aucun prétexte. C'est pour cela que je vous contacte.

Il y a deux points sur lesquels nous pouvons avancer

Le premier concerne la validation w3c. Il apparait que tous les fichiers SVG créés à partir d'Inskape, et pas seulement les miens, biens que corrects ne passent pas à cause du DTD au validateur https://validator.w3.org/ mais sont corrects au vu de l'alternative proposée de https://validator.w3.org/nu/. J'ai bien vu que vous avez passer en revue mes fichiers pour mettre en exergue cette anomalie.

Le second point nécessite la lecture de l'article Commons:Ownership_of_pages_and_files/fr Je ne vois pas l'intérêt de dupliquer sans crédit à l'auteur original ; par exemple le fichier File:Cadoene de Gabriac.svg en File:Blason famille fr de Cadoëne de Gabriac.svg, je n'ai rien contre le fait d'améliorer ou de corriger un fichier, et ainsi pourvoir avoir un historique de ce qui est apporté, mais il faut que cela en vaille le coup, et que les modifications soient en cohérence avec les sources citées. Comme vous l'avez mentionné, nous ne sommes pas sur un réseau social, mais il est toujours possible d'échanger nos remarques de façon constructives. Nous pouvons apporter au projet blason bien plus ensemble. Il pourrait s'enrichir de nombreux nouveaux blasons, si nous ne perdions pas de temps dans des corrections microscopiques :-)

Je vous prie donc respectueusement de revoir votre procédé, ne souhaitant pas aller plus loin, ni signaler le problème. Salutations, bien cordialement Zardoz91 (talk) 15:49, 14 July 2024 (UTC)[reply]

Bonjour Zardoz91,

La validation w3c concerne tous les éléments web : html, css, svg, etc.

L'alternative https://validator.w3.org/nu/ ne valide que le html, sur l'autre il faut bien renseigner l'url de l'image.

Concernant l'appropiation d'un blason, il n'y en a pas : c'est un blasonnement identique représenté différemment ; une appropriation serait de se déclarer auteur du blasonnement, par exemple.

Enfin, il ne s'agit pas de « mettre en exergue » des erreurs de code, il y a là qu'une question de norme, et le plus souvent le fait d'être invalide n'impacte pas le résultat visuel. Concrètement, signaler correctement le statut w3c permet surtout d'éviter que d'autres reprennent un modèle qui ne passe pas au validateur - exemple, lorsque j'ai corrigé celui-ci, le modèle d'écu que j'ai repris était non valide (mais le fait qu'il manque une valeur offset dans le dégradé ne change rien, puisque le défaut "0" est appliqué lors du rendu par le navigateur - au jour d'aujourd'hui).

Après, si on prend par exemple ce fichier, quelle que soit la version, on voit bien que s'il y a un problème ce n'est pas dans le code, celui-ci étant bien la dernière chose à régler.

Il en est de même pour le Cadoene de Gabriac.svg.

Aller plus loin sur ce sujet relèverait sans doute d'une discussion de forum, mais pourquoi pas.

Kontributor 2K 16:35, 14 July 2024 (UTC)[reply]

Bonsoir,

Le problème avec Inkscape est la reconnaissance du DTD, le validateur https://validator.w3.org/nu/ ne se contente pas de valider le html, faites le test avec le fichier Fontanes.svg

Vous obtiendrez

Info: Using the preset for SVG 1.1 + URL + HTML + MathML 3.0 based on the root namespace.

Error: SVG element stop is missing required attribute offset.

At line 1, column 302 in resource https://upload.wikimedia.org/wikipedia/commons/5/5b/Fontanes.svg

La différence avec https://validator.w3.org/ est qu'il ne s'appuie pas sur la DTD. (c'est d'ailleurs signalé sur la page : As an alternative you can also try our non-DTD-based validator.)

L'outil fonctionne, il a bien détecté une erreur SVG

Les deux validator propose les mêmes input URI, Upload ...

Cordialement Zardoz91 (talk) 18:24, 14 July 2024 (UTC)[reply]

OK,

Je n'utilise pas Inkscape, et je n'aurais pas l'idée d'utiliser un validateur non-DTD…

Je suppose que ce dernier principe a aussi été adopté par le fameux Script qui a été à l'origine d'une remise en question chez bon nombre d'utilisateurs,

Cordialement,--Kontributor 2K 18:34, 14 July 2024 (UTC)[reply]

Bonsoir, Merci d'arrêter de dupliquer mes oeuvres, si j'en juge vos derniers upload, vous recopier et renommer des blasons que j'ai déjà créés pour le projet blason et pour illustrer l'article de l'armorial du Gévaudan. Dans la négative je ferai appel au administrateurs en détaillant vos pratiques, inadéquates, le harcelement sur mes fichiers et contournement abusif de la licence. je ne manquerai pas non plus d'ouvrir un sujet sur le projet blason. Soyez constructif et respecter l'antériorité des oeuvres, je prends en compte vos remarques et fait en sorte d'y répondre. Je ne remet pas en cause vos modifications lorsqu"elles sont fondées. Cordialement PI : le problème de DTD sur le validator W3C est réglè. Zardoz91 (talk) 19:02, 15 July 2024 (UTC)[reply]