Opening the settings dialog and hitting "apply" (even without any changes) produces a warning about some limitation in KPA and that the kategories have been renamed (they haven't!). 1) I do not understand the warning (neither the content (in German), nor why it shows up) 2) If I hit "continue" in the warning dialog, my annotation dialog layout is completely mangled and the preview image is tiny My category names are not the default names. Reproducible: Always Steps to Reproduce: 1. open a KPA database from 4.5 2. look at the annotation dialog and remember its layout - close it 3. open KPA settings (do not change a thing) 4. hit "apply" or "ok" 5. a warning should appear (warning.png) 6. in the warning dialog hit "continue" 7. close the settings dialog 8. look at the annotation dialog again. Actual Results: annotation dialog layout has changed (mangled.png) Expected Results: annotation dialog layout should stay the same (ad.png)
Created attachment 95661 [details] warning dialog after hitting "apply" appears with a pre-4.6 database (last rev. before 4.6.2 was 4.5... from git master)
Created attachment 95663 [details] annotation dialog as it was and should be (in my case)
Created attachment 95664 [details] mangled annotation dialog after settings & warning
I just tried this with another of my databases with funny results: "kphotoalbum -c ...some index.xml" starts with German translation and produces this error "export LANG=de;kphotoalbum -c ..." starts in English and *does not produce this error* Even with corrected LANG setting, the error always appears with the German localisation, not with English. I tried Italian and Dansk (hello Jesper!) - both did not show the warning dialog (in both languages the settings dialog is only partially translated).
Your last comment makes me think that it might be related to the database update to file version 6. Upon upgrade from an older version, "Persons" is renamed to "People", and "Locations" is renamed to "Places". Do your databases have any of these category names?
Just some additional info, not necessarily relevant for the bug: I actually got some very strange problems I still don't understand when using LC_ALL=C (also using the German locale normally). So it's probably currently not a good idea to start KPA with the C locale (using anything but a testing database) … The layout problem is a bit weired though, as I don't think our category name changes have anything to do with the layout … I'll try to reproduce it anyway.
Created attachment 95678 [details] empty index.xml file for KPA with my custom categories
I just added an empty xml-file to be used for testing with any small set of images. With this file it is possible to recreate the strange warning (not the mangled AD-layout, yet). Follow these steps: * create a new folder an put a few images into it (eg. those from the demo db) * download leer.xml (attached above) * say: > export LANG=mist - (This creates an invalid LANG variable, so KPA starts up in English, no matter what.) * say:> cp [path to]/leer.xml index.xml * say:> kphotoalbum -c index.xml - In KPA switch language to English and look around, maybe create a custom layout for annotation - save and exit * Inspect (with editor or less) the index.xml and note the category names: One of them is "Personen". * say:> export LANG=en_US - (this is valid) * say:> kphotoalbum -c index.xml - In KPA open the settings dialogue and change some trivial matter (eg. aspect ratio of thumbnails) and save. - In KPA switch language to German - save and exit * Inspect the index.xml and note the category names: One of them is still "Personen". * say:> kphotoalbum -c index.xml - Now KPA should start with menus and dialogues translated to German - In KPA open the settings dialogue and only hit "Anwenden" or "OK" ==> the strange warning should appear. - In KPA say "Fortsetzen", "OK" and leave the settings dialogue - (check the AD-layout) - save and exit * Again inspect the index.xml and look for category "Personen" - it is renamed to "People". All the other categories are unchanged. :-(( Finish of Demo So why in the world would someone translate one of *my* category names? What a host of unthought of side-effects could this have? (the mangling of the AD-layout might be one) I see the good intention: provide a means to transfer categories between people who use different languages and make this "invisible" by retranslating on the fly ... but in my eyes this renaming is a no-go (These are *my* data, I named them 11 years ago, I use them in a lot of image DBs in the family (who all use different revisions) and this just messes up a lot.) IMHO, it would be better to add a new xml attribute (like it was done with "positionable" in the past) eg. global-name="location" (and global-name="person", ...). So everybody could keep his or her own category names and still have universal interoperability. These global names should be selectable from a predefined set (somewhere in the settings), but nobody should be able to rename them. And they should be translated in GUI only, never in the DB. This might even be a replacement for "positionable=0/1" (?)
(In reply to Johannes Zarl-Zierl from comment #5) > Your last comment makes me think that it might be related to the database > update to file version 6. Upon upgrade from an older version, "Persons" is > renamed to "People", and "Locations" is renamed to "Places". > > Do your databases have any of these category names? Yes - see comment and test case below. When in English, KPA does not recognize "Personen", only when used with German interface. NB: Great work, making the thumbnails (down-)scalable again!
After further investigation, I can at least explain why this happens (not the layout thing, this must be something else! But the category name thing). It's really a (hopefully rare!) corner case. During the database update to version 6, the old localized category names like "Personen" in German are fixed to be their C locale counterparts (they should never have been created in this way, but KPA did it like for ever, and before we implemented face recognition with a second database to keep in sync with KPA's database, nobody noticed it). From database version 6 on, KPA expects the standard categories to be in English inside the database (the users will see the localized name anyway). So, if you do/did the dbv6 update with another locale than the one you normally use and the database was created with, the update does not recognize the localized standard categories and does not fix them. If you save the database afterwards, you actually get a v6 database still containing the localized category names ("Personen" in your case which should be "People"), which shouldn't be there anymore. If you use KPA after that with the "real" locale, it finds a localized standard category which should have the C locale name. So the "hidden" rename action happens when opening the settings dialog when the category page is filled with data. You don't have to change anything to make it happen. It happens as soon as you open the settings dialog. Well, here we are … this only happens if you run this one and only particular KPA session where the dbv6 updates take place with another locale than your "normal" one. We have no chance to detect whether you are doing so or not, so we can't warn you about it. But you can fix your database e. g. if you take a backup version (5) with still has the localized standard category names (or change the version by hand to 5 if you have another one with localized category names), and run KPA one time against it with your real locale to let it do the dbv6 update. A backup will be created and the database will be saved automatically (at least with version 4.6.2). The fixed db you should not cause problems, as long as you don't do things like start it with the C locale and add localized categories which then won't be detected as such. And yes, the localized "standard category" names are a real PITA, but I see no chance to cheat the gallows about this … except for a KPA rewrite :-P
OK, now I understand this message. As only one of my "standard" categories is beeing renamed I seem to have 2 or 3 choices: 1) rename (manually) "Personen" to "benannte Lebensform" to make it untranslatable. So I have a DB without any of the 3 defaults. Would that be a problem? Now? In the foreseeable future? 2) rename my location and keyword categories so that they are translated also and go with the current mainstream development. con: My gut feeling is, that this translating of *some* categories might cause serious malfunction in the future. Eg. some developer assumes the presence of one of the default categories, which might not be present at all (say, in an image DB of bacteria-pictures). pro: better interoperability 3) In variation of 1) add the 3 default categories and leave them empty. As for this bug message: I think, the wording of the warning message could be improved, as to which categories are renamed and how (only internally and than translated back) and why. I will see, whether the AD-layout gets another unwanted makeover. As I could not reproduce it with any other DB except my own, this should be not too important for now. Thanks for Your input!
Hey, I was just trying to go along with the mainstream (rename my categories to the default names) and - as predicted - I run into the first inconsistency: * make backup copy of index.xml * LANG=mist (to force KPA to English) * KPA (starts in English) settings: rename "Personen" to "People" (OK) rename "Ort" to "Places" (OK) try to rename "Motiv u. Stichwort" to "Keywords": "" "Can't change the name "..." to "Keywords": "Keywords" is a special category name, which is reserved and can't be used for a normal category. "" Back to square one! There is no category named "Keywords" in my index.xml. So, why am I not allowed to recreate the default one and join the crowd? There should be a way back for the repentant.
Actually, we're thinking about kicking out those categories with translations. They already caused a lot of problems and headache, and still do. So … thanks for proving that we really can't handle this in a safe way ;-) "Keywords" is actually a special category, just like "Folder". You can't use those as a "normal" category, and also won't be able to use them in this way, even if the translations would be removed.
OK, this "Keywords" anomaly is easily fixed with a text editor > %s/Motiv u. Stichwort/Keywords/g and KPA is happy. However. This renaming messed up my AD-layout. Quite predictably. I just tried this with another of my numerous DBs: even renaming only the two allowed categories (Places and People), using the settings dialogue, mixes up the AD-layout: The two "new" categories are added at the end of the layout, which is bottom right. The layout.dat does not know about changes done in index.xml and thus ... KPA does not keep tabs on these categories (which is the old and which is the new name). A renamed category seems to be a whole new thing for the program. All KPA does is something my editor-line above does also. Therefore, we might close this bug and call it a "limitation". 2 last comments: * the warning message after renaming categories appears twice, if two categories are renamed in one go. * the AD-dialog layout does not save the size of the preview image. After every restart, it is reset to a smaller size. See here: https://bugs.kde.org/show_bug.cgi?id=340121
What is special about "Keywords"? I did not have it for > 10 years and I did not see any side effects, that I might attribute to this. Now I renamed the category per editor and it did not hurt (until now). I understand, that "Folder" and "Tokens" are special. They don't appear among the normal categories in the settings dialogue. "Keywords" is in the list (at least in the demo-DB). Maybe this is a long forgotten legacy (a.k.a. hazardous waste site ;-)?
Created attachment 96288 [details] screenshot of startup message (latest git) This is, what I saw from the latest build. Seems to be somewhat a result of this discussion here (?) Johannes & Tobias, you are doing a great job. Merry Christmas!
You're right :-) After a close inspection, we realized that those translatable category names cause some problems that actually can't be fixed at all. So we decided to remove them. If you want, you can test the current git state. It's about category names and the category settings dialog. Have a backup, we had to change a lot of code all over KPA ;-) If you find some bug/regression, please inform us (via mailing list or IRC). Merry Christmas and nice holidays :-)
I think this is no longer present in current versions of KPhotoAlbum. I'm therefore closing it. Please reopen it if you think my assessment is incorrect/incomplete.