<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body style='font-size: 10pt; font-family: Verdana,Geneva,sans-serif'>
<p>Hi Régis,</p>
<p>In general - you are right - but the problem with standards it that they are often ignored. Browser developer companies (like Google) basically ignore 80% of the W3C standards and just implement what they want. I was involved with SVG standardization a decade ago - and I have to say - it was a big disappointment to see what the big companies did with standards - even if it were their own employees who worked on the standards documents.</p>
<p>The SVG param specification is in "working draft" stage - it is from W3C, not an invention by QGIS - but in my opinion, it is much easier to use than the i18n section that you quote. And I don't think it is implemented in any browser or authoring system (like Inkscape, Illustrator, etc.)</p>
<p>See <a href="https://www.w3.org/TR/SVGParam/#AdaptTextToUse">https://www.w3.org/TR/SVGParam/#AdaptTextToUse</a></p>
<p>Adapt text in an icon or button is exactly a use case in the SVG param specification (working draft).</p>
<p>Andreas</p>
<p id="reply-intro">On 2020-07-28 10:15, Régis Haubourg wrote:</p>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">
<div id="replybody1">
<div>
<div dir="auto">Hi,
<div dir="auto">I think we should better follow the standard for internationalizing instead of progressively making a proprietary format. </div>
<div dir="auto">See <a href="https://www.w3.org/TR/SVGTiny12/i18n.html" target="_blank" rel="noopener noreferrer">https://www.w3.org/TR/SVGTiny12/i18n.html</a></div>
<div dir="auto">Cheers!</div>
</div>
<br />
<div class="v1gmail_quote">
<div class="v1gmail_attr" dir="ltr">Le mar. 28 juil. 2020 à 09:57, Andreas Neumann <<a href="mailto:a.neumann@carto.net" rel="noreferrer">a.neumann@carto.net</a>> a écrit :</div>
<blockquote class="v1gmail_quote" style="margin: 0 0 0 .8ex; border-left: 1px #ccc solid; padding-left: 1ex;">
<div style="font-size: 10pt; font-family: Verdana,Geneva,sans-serif;">
<p>Hi all,</p>
<p>I am only loosely following this discussion.</p>
<p>But about the internationalization: couldn't we use the same param - mechanism we already have for fill-color, stroke-color, opacity, etc. and extend it to the content of <text/> elements?</p>
<p>That would solve internationalization and would also be usefuly for dynamic text in icons anyway - there might be some use cases for this even without internationalization.</p>
<p>Just an idea,</p>
<p>Andreas</p>
<p id="v1m_8777697399697761416reply-intro">On 2020-07-28 02:39, Nyall Dawson wrote:</p>
<blockquote style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0;">
<div style="margin: 0; padding: 0; font-family: monospace;">On Mon, 27 Jul 2020 at 21:57, Jonathan Moules<br /><<a href="mailto:jonathan-lists@lightpear.com" rel="noreferrer">jonathan-lists@lightpear.com</a>> wrote:
<blockquote style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0;"><br />Hi List,<br /><br />The more I look at the current SVG icons, the more I'm thinking it<br />really needs some TLC (Tender Loving Care). As far as I can tell, icons<br />are categorised by the directory they're in, so if you want an icon to<br />appear in two categories, you put the icon in there twice... and so<br />that's just what has happened! I suspect the current set has simply<br />accreted over time.</blockquote>
<br />For reference: I'm totally in agreement that we need to improve the<br />DEFAULT set of svg files, and that the resource sharing plugin isn't<br />the best solution here. It's a great solution for some use cases, but<br />we need to improve the out-of-the-box experience in this regard and<br />that means extending the default set.<br /><br />
<blockquote style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0;">My thoughts:<br />* Move the svg's into a single directory. (Though would break any<br />current projects symbology using them I guess?)</blockquote>
<br />Yes -- we CAN'T do this. What we've got now has to stay, in its<br />current structure, and without renaming.<br /><br />
<blockquote style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0;">* Use a metadata file to categorise them, so you get a list of<br />categories as now and a single symbol can be in multiple categories.</blockquote>
<br />We could potentially add tags to the svg files themselves to add this<br />information.<br /><br />
<blockquote style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0;">* Add a search feature so the user can quickly find "museum" without<br />having to guess where it has been categorised.</blockquote>
<br />Big +1 to this. Especially if we also add search by tag support!<br /><br />
<blockquote style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0;">* Clean up the current symbols by removing duplicates.</blockquote>
<br />Again, we can't do this without risking breaking people's existing<br />projects (which is off-limits!)<br /><br />
<blockquote style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0;">* Add the font-awesome symbols (per my thread on the User List) to fill<br />in the gaps and flesh out the collection. As a bonus, it comes with<br />metadata for categories and search terms (YAML files).<br /><br />* bonus - metadata is internationalised so "museo" (IT), "muzeu" (RO),<br />etc would also work for finding that museum.<br /><br />Thoughts?</blockquote>
<br />Sounds good to me! To clarify -- are you volunteering to lead this effort?<br /><br />Nyall<br /><br />
<blockquote style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0;"><br />Cheers,<br />Jonathan<br /><br /><br />_______________________________________________<br />QGIS-Developer mailing list<br /><a href="mailto:QGIS-Developer@lists.osgeo.org" rel="noreferrer">QGIS-Developer@lists.osgeo.org</a><br />List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank" rel="noopener noreferrer">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br />Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank" rel="noopener noreferrer">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></blockquote>
_______________________________________________<br />QGIS-Developer mailing list<br /><a href="mailto:QGIS-Developer@lists.osgeo.org" rel="noreferrer">QGIS-Developer@lists.osgeo.org</a><br />List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank" rel="noopener noreferrer">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br />Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank" rel="noopener noreferrer">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></div>
</blockquote>
<p><br /></p>
</div>
_______________________________________________<br />QGIS-Developer mailing list<br /><a href="mailto:QGIS-Developer@lists.osgeo.org" rel="noreferrer">QGIS-Developer@lists.osgeo.org</a><br />List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank" rel="noopener noreferrer">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br />Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank" rel="noopener noreferrer">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></blockquote>
</div>
</div>
</div>
</blockquote>
<p><br /></p>
</body></html>