I have one question and one comment about your plugin.
But first of all, thank you for all your work, you did a super job !

My question is: is this plugin compatible with Lightroom 2? Do you know if we can encounter any limitations / problems by using it?

Its results should work fine in Lightroom 2, but there are a bunch of new things I should add to it that are new in 2.0. Sigh, my todo list is just way too long…

My comment: you said you replaced “Jog identifier” by “Blog URL”. I don’t find this solution really clean, because you are changing the semantic of an element defined by the IPTC-standard which says:
“job id: Identifier for the purpose of improved workflow handling. This ID should be added by the creator or provider for transmission and routing purposes only and should have no significance for archiving.”
I know that all tool-vendors like Adobe aren’t always following 100% from these standards, but when they are I find important to keep the original semantic of the implemented elements.

When it comes down to it, you’re right. I know it’s fine for me (in my own little world where I don’t need to interact with anyone else, IPTC-wise) to hijack the fields for my own random uses, but it’s a slippery slope. I’ll put a footnote there referencing this comment, so that others at least know that I’m choosing to do something explicitly outside the design of that field. —Jeffrey

Thank you!
Etienne

- The messing up of the meta data browser also applies to “ISO Speed rating” which I renamed to just “ISO”

- This logic should apply to ALL field names which MIGHT end up being used SOMEWHERE for indexing. This is most likely to affect everything which ends up in the database table with column “kindName” set to “AgEnumeratedMetadataTagKind”. The information in this table is responsible for the Metabrowser Data.

- Currently I’ve found troublesome: “ISO Speed Rating”, “Aperture” and “Shutter Speed”

Another solution for fixing bad values is this:
-EXIT Lightroom (mandatory)
- Open your database file with SQLiteDatabaseBrowser
- Go to the “Browse” tab and open the “AgLibraryTags” table
- Delete all offending values which might be a tedious task
- Restart Lightroom
- Choose all or only the candidates, if you know them, and choose “Read Metadata from File”.
- Your metadata should be fixed now

By all means usse the “Metadata-Viewer Preset Editor” if you want to choose labels in the metadata module.
This has the drawback that you do not change the names globaly though.

I’ve come to the conclusion that Adobe took a bad road to implement this. I wonder if the ever build localized software It is so f*****g stupid to store these together with their descriptors in the same column of the same table with a parent column creating the structure. Why they did not choose to use abstract names for distinct EXIF values in a separate translation table is written in the stars.

Complicated software creates complicated problems

+++ SEVERE +++ SEVERE +++ SEVERE

Did I say SEVERE already?

Well … here it is:

- Do NOT change the string “Aperture/FStops (when part of a larger description)” from “f / ^0″ to “f/^0″ to get rid of the extra spaces. And do not change that thing to any other string.

For various reasons …

What happens is this:
- On importing pictures Lightroom writes some infos about the files into its database. Specificaly into the AgLibraryTags table of your .lrcat file. It happens to be a SQLite Database files in case you did not know that …
- The “name” column contains values which are shown in the Metadata browser on the left side in grid view. Along goes the number of files which carry this “attribute”. This is IMHO a way to speed up metadata based browsing and filtering.
- NOW on displaying the metadata browser Lighroom loads these values and severly chokes on displaying aperture values as it tries to calculate “f devided by 2.8″ (and all other apertures imported whith the last set).
- It displays the following error message (with your aperture value instead of 2.8):

[string "return f/2.8"] :1: attempt to perform arithmetic on global 'f' (a nil value)

and does NOT show the list of aperture values. Instead every time the list should get updated the error occurs and makes Lightroom unusable.
- Another reason to not change this value is that you would end up with a messed up list.
You would end with “f / 2.8″ and “F /2.8″ values if you change the template to use an uppercase letter F instead the lower case one.

A possible fix right after you did it:
- Remove the imported pictures from the catalog. This will also update the AgLibraryTags table and remove the offending values.
- EXIT Lightroom (mandatory!)
- Change your TranslatedStrings.txt by removing the line:
"$$$/AgLibrary/Exif/FStopTemplate/ASCII=f/^0"
- Having set this back to default you may restart Lightroom an import the files again. Everything should be fine now.

BTW, on editing … you may want to Copy&Paste the “line breaked” version you will get when clicking on “View this page” into a manualy created text file instead of using “Save this link”. It works like a charm and is much easier to edit.

Don’t ask me why Adobe did something stupid like this. If it is a string, it is a string and should not by any means used to make a calculation after some wild guessing about its contents. I don’t quiet understand why they did not simply use the numerical value. The label of the field is stored as a foreign key in the column parent anyways … sigh …

It does not work to edit the values in the database itself. I tried it using SQLiteBrowser you may get from Sourceforge. I fixed the offending values to contain a space and Lightroom did not show the error again but duplicate entries for every aperture I “fixed”.

Hope this helps someone …

The comment went down on editing and now may as well serve as a comment on Lightroom. Not bad either Both applies now …

An important information which really should be mentioned in the installation instructions regarding the TranslatedStrings.txt:

The file has to be put into a subfolder under Resources which reflects the language code of your operating system an not that of Lighroom! If its not there, just create it.

Lightroom seems to be a bit stupid here. Or a lot. The help files are taken from the “en” folder, no matter what you create under lets say “de” in a help folder.

This seems to make sense since the help file might always be in the language the main distribution is in. Or not. So what sense is there in configuring font names and size in a file “obviously” created for, well, translated strings.

This software seems to be unready in some (or many?) parts. Why is this file not in XML as many others? Why is font configuration not implemented in the GUI?

Oh … and another thing: Check color fidelity (trueness) of your Canon RAWs regarding red tones. Compare to the supplied Canon Tools and you’ll notice that Adobe way off of that what the camera thinks and hence the Canon Tools.

So much work has been put into this and some people leave the thing alone because of frustration.