Hmm do you mean the web galleries it creates or actually storing multilingual descriptions in the image?

Both, but priority I would put on storing multilingual descriptions in the image - since nontextual gallery controls are OK for the most of cases

This was discused recently on the list. The conclusion had been come to that F-spot must remain loyal to the open specifications, that is, that the XMP data added to the photos must be readable by other XMP-compliant applications. I presented three proposals as to how this could be accomplished:

For the sake of the examples, one should know that the word "Dog" in English is "Perro" in Spanish. "One" in English is "Uno" in Spanish.


1) Have extra data added to the tags that would not be shown on the interface. This data would include an identifier so that F-spot could associate tags, would contain the code of the language, and the actual keyword. So, for example, a photo could have these two tags:
"7484567::en::Dog"
"7484567::sp::Perro"
"3924713::en::One"
"3924713::sp::Uno"

When F-spot is in English mode, it would use the tag with the "en" language code, and the "sp" language code for Spanish.

The drawback to this method is that other XMP-compliant applications would show the meta-metadata. Ugly.



2) Have the different languages inside a single tag, like so:
"en::Dog::sp::Perro"
"en::One::sp::Uno"

Of course, this also has the downside of other XMP-compliant applications showing ugly tags.



3) Write the XMP as two seperate tags, and have a seperate block of data that F-spot would use to associate the tags and to specify which language. This extra block of data could be called FSF (F-Spot Format or F-spot Specific Format) if it needs a name. So the XMP tags would be:
"Dog"
"Perro"
"One"
"Uno"

And the FSF block would be:
<fsf>
    <tag>
        <value lang="en">Dog</value>
        <value lang="sp">Perro</value>
    </tag>
    <tag>
        <value lang="en">One</value>
        <value lang="sp">Uno</value>
    </tag>
</fsf>

The final block of data that is written to the photo would be:
<x:xmpmeta xmlns:x='adobe:ns:meta/' x:xmptk='XMP toolkit 3.0-28, framework 1.6'>
<rdf:RDF xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#' xmlns:iX='http://ns.adobe.com/iX/1.0/' xmlns:dc='http://purl.org/dc/elements/1.1/'>
  <rdf:Description>
    <dc:subject>
      <rdf:Bag>
        <rdf:li>Dog</rdf:li>
        <rdf:li>Perro</rdf:li>
        <rdf:li>One</rdf:li>
        <rdf:li>Uno</rdf:li>
      </rdf:Bag>
    </dc:subject>
  </rdf:Description>
</rdf:RDF>
<fsf>
  <tag>
    <value lang="en">Dog</value>
    <value lang="sp">Perro</value>
  </tag>
  <tag>
    <value lang="en">One</value>
    <value lang="sp">Uno</value>
  </tag>
</fsf>

In this method, the other applications, which do not understand FSF, would simply ignore the FSF block and display the four tags. If the developers of other applications wish to include FSF support in their products, then so be it.

please read the XMP specification and refine your proposal based on the rdf language elements that it allows.

My proposal has nothing to do with XMP. I purposely do not want to change the XMP data, so that other programs could read it.

I'm proposing something added _after_ the XMP data that only F-spot recognises, to facilitate identifying which tags are in which language, and which tags from language XXX corrospond to which tags in language YYY.

If XMP specifications allows same tag in different languages, why not use it?

From the mailing list archives, I see that XMP uses what are known as "language alternative arrays" to store multiple versions of the same metadata. But it seems it allows it only for some very specific fields, like Title. It _may_ possible to use it for fields for which it is not explicitely allowed. However, the language alternatives arrays apparently can't be used for keywords.

Most of this post was cut-and-paste from the mailing list, and not my own words. Plagerism is faster than paraphrasing!

The main problem I see with this bug is how to put this into a UI that's sane for normal users. Multi-lingual XMP is great, but if only a very few number of users will use it, it might not be worth hacking this into the UI (for which I see the need of rather invasive changes, if we want to make this at least somewhat discoverable / usable).

> The main problem I see with this bug is how to put
> this into a UI that's sane for normal users.

How about a spinbox in the Options for selecting how many fields to have? If it's more than one, then have text fields for labelling them.

Reopening as I think the requested information has been provided.

I'd rather not see a preference for stuff like this, as per our vision statement that "keeps it simple": http://f-spot.org/Goals

When I think about it: it's also not just a matter of UI: this would affect our database schemas too. Which I don't want to see happening for a feature that only a minority of the users will probably use.

We could categorize this under "specialized photo manipulation software". Unless it can be done without any changes to F-Spot core, I'd rather not have it in, to keep our core clean, lean and mean. Should be done as an external tool. Taglib# supports language-alternatives and will preserve them on write.