<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">https://www.w3.org/TR/SVGTiny12/i18n.html</a></div><div dir="auto">Cheers!</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mar. 28 juil. 2020 à 09:57, Andreas Neumann <<a href="mailto:a.neumann@carto.net">a.neumann@carto.net</a>> a écrit :<br></div><blockquote class="gmail_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="m_8777697399697761416reply-intro">On 2020-07-28 02:39, Nyall Dawson wrote:</p>
<blockquote type="cite" 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" target="_blank" rel="noreferrer">jonathan-lists@lightpear.com</a>> wrote:
<blockquote type="cite" 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 type="cite" 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 type="cite" 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 type="cite" 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 type="cite" 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 type="cite" 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 type="cite" 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" target="_blank" rel="noreferrer">QGIS-Developer@lists.osgeo.org</a><br>List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noopener noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noopener noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></blockquote>
_______________________________________________<br>QGIS-Developer mailing list<br><a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank" rel="noreferrer">QGIS-Developer@lists.osgeo.org</a><br>List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noopener noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noopener noreferrer noreferrer" target="_blank">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" target="_blank" rel="noreferrer">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></blockquote></div>