Ticket #877 (Closed: fixed)

can you please elaborate? what you need is a metadata class, that groups together attributes for a metadata: class Metadata { public: Glib::ustring getDcName(void); Glib::ustring getLocalizedName(Glib::ustring locale); Glib::ustring getId3Tag(void); }; and a container, holding all the 'known' Metadata objects together: class MetadataContainer? { public: Ptr<Metadata>::Ref getByDcName(Glib::ustring dcName); Ptr<Metadata>::Ref getById3Tag(Glib::ustring id3Tag); Ptr<Metadata>::Ref getByLocalizedName(Glib::ustring name, Glib::ustring locale); };

Yes, I need these 2x3 functions. It would be nicer if I did not have to provide the locale, but MetadataContainer? were a LocalizedObject?, and the central GLiveSupport class created a localized instance at login, which I could get by, say, gLiveSupport->getMetadataContainer(). Probably Metadata needs to be a LocalizedObject?, too, then -- or maybe not. I also need a function to return all known metadata types; something like this: class MetadataContainer? { public: typedef something iterator; iterator begin; iterator end; } where *() of an iterator would be a Ptr<Metadata>::Ref.

(of course I meant begin() and end()) The config file of MetadataContainer? will be a good place to put the search/browse preferences, too. (Which metadata categories Simple Search does the search in, what the defaults are for the Browse categories.)

yes. but, what do you think about localization? I guess that should go to its regular place, not into this XML file...

I think if I only use one language ever, I should be able to add/remove metadata categories at one place only. Maybe we could make localization optional? Have the { "dc:creator", "Creator", "TPE2" } etc triples in metadataContainer.xml, and a metadata table in xx_YY.txt with entries like Creator:string { "Creator" } or Creator:string { "Erstellt von" } but if this line is missing (in all fallback files, too), then we just use the string from metadataContainer.xml.

I added MetadataType? and MetadataTypeContainer? classes, with test cases into the core module. Please take a look. it does not include the getByLocalizedName() function, as that would be somewhat complicated. Do you need such a function? As for localization, the XML document describing the metadata types store the localization keys, that are expected to contain the localized strings. The objects rely on the current resource bundle held by the MetadataTypeContainer?, and the related localization key to get the localized strings. I still think that not having a localized resource is a grave issue. (and, also please note that the localization framework does have a fallback mechanism itself...) anyway, take a look on what changes you'd need for what I've done...