Hi, I think we should better follow the standard for internationalizing instead of progressively making a proprietary format. See https://www.w3.org/TR/SVGTiny12/i18n.html Cheers!
Le mar. 28 juil. 2020 à 09:57, Andreas Neumann <[email protected]> a écrit : > Hi all, > > I am only loosely following this discussion. > > 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? > > 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. > > Just an idea, > > Andreas > > On 2020-07-28 02:39, Nyall Dawson wrote: > > On Mon, 27 Jul 2020 at 21:57, Jonathan Moules > <[email protected]> wrote: > > > Hi List, > > The more I look at the current SVG icons, the more I'm thinking it > really needs some TLC (Tender Loving Care). As far as I can tell, icons > are categorised by the directory they're in, so if you want an icon to > appear in two categories, you put the icon in there twice... and so > that's just what has happened! I suspect the current set has simply > accreted over time. > > > For reference: I'm totally in agreement that we need to improve the > DEFAULT set of svg files, and that the resource sharing plugin isn't > the best solution here. It's a great solution for some use cases, but > we need to improve the out-of-the-box experience in this regard and > that means extending the default set. > > My thoughts: > * Move the svg's into a single directory. (Though would break any > current projects symbology using them I guess?) > > > Yes -- we CAN'T do this. What we've got now has to stay, in its > current structure, and without renaming. > > * Use a metadata file to categorise them, so you get a list of > categories as now and a single symbol can be in multiple categories. > > > We could potentially add tags to the svg files themselves to add this > information. > > * Add a search feature so the user can quickly find "museum" without > having to guess where it has been categorised. > > > Big +1 to this. Especially if we also add search by tag support! > > * Clean up the current symbols by removing duplicates. > > > Again, we can't do this without risking breaking people's existing > projects (which is off-limits!) > > * Add the font-awesome symbols (per my thread on the User List) to fill > in the gaps and flesh out the collection. As a bonus, it comes with > metadata for categories and search terms (YAML files). > > * bonus - metadata is internationalised so "museo" (IT), "muzeu" (RO), > etc would also work for finding that museum. > > Thoughts? > > > Sounds good to me! To clarify -- are you volunteering to lead this effort? > > Nyall > > > Cheers, > Jonathan > > > _______________________________________________ > QGIS-Developer mailing list > [email protected] > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > > _______________________________________________ > QGIS-Developer mailing list > [email protected] > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > > > _______________________________________________ > QGIS-Developer mailing list > [email protected] > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
