Bug 448071 - "People" tag should not depend on interface's language
Summary: "People" tag should not depend on interface's language
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Tags-Keywords (show other bugs)
Version: 7.4.0
Platform: Flatpak Linux
: NOR minor
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-01-07 15:44 UTC by MarcP
Modified: 2022-01-08 15:09 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In: 7.5.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description MarcP 2022-01-07 15:44:43 UTC
SUMMARY
People recognized in photos are, by default, placed within the "People" keyword. There is one problem though. When digikam's language is changed, the name of that tag changes too. By default in English it's "People", but for example, in Spanish it's "Personas". If a user changes digikam's language while already having a picture library, the default place of creation for new people will be that of the translation, leading to two separate categories of people within digikam.

I don't know what would be the best way to approach this issue. I've though of some possibilities:

- Maybe we could force that tag to be called People regardless of the user's language. (but that would force the user to move all the people tags within People manually)

- Display the tag "people" in the user's language, but internally use People when writing the metadata (but that would "break" existing picture libraries that already use the word in another language, without the user noticing)

- Setting an option in Digikam to select the location of the "People" category within the tag tree.

- Digikam detecting automatically the location of the People category, regardless of the language, and defaulting the creation of new people within it.

- Removing people completely from the tag hierarchy, and only use them in the People panel in a flat list (a bit of a radical approach, but would solve bug 416213 and bug 392008)


Anyway, I just thought of bringing up this issue, as I have been experiencing it these days since my flatpak digikam seems to have defaulted to English. Thanks for your time.

STEPS TO REPRODUCE
1. Start digikam, detect and tag some faces.
2. Change digikam's language and restart.
3. Start digikam again, and tag some more people

OBSERVED RESULT
A second "People" tag tree has been created.

EXPECTED RESULT
New people should be placed inside the existing People category.

SOFTWARE/OS VERSIONS
Digikam 7.4 in Ubuntu 20.04 LTS
Comment 1 Maik Qualmann 2022-01-07 16:46:14 UTC
No, People tag does not change if you change the language ... under the following condition:
The people tag exists and there are already people under it. The people tag is not recreated or renamed when the language is changed. You can even give the People tag a new name yourself.
I guess you imported images with People and Personas in the tag path, so that 2 people trees are created. This cannot really be prevented because most of the users want their tag names in their language.

Maik
Comment 2 MarcP 2022-01-07 16:50:20 UTC
In my specific case, I was using a library in digikam set in Spanish (so Personas was the name of the category), but after some update in the flatpak channel it defaulted to English (I didn't mind) and new people were placed under the "People" tag, so I had both.
Comment 3 MarcP 2022-01-07 18:36:25 UTC
Ok, I did a quick test and, with the interface in English, it respected my previous "Personas" tag. So I understand digikam already tries to find out the current tag under which people will be created, no?
Comment 4 Maik Qualmann 2022-01-08 15:09:45 UTC
Git commit bf167894ccd12a406b9560b635640a923dc101d2 by Maik Qualmann.
Committed on 08/01/2022 at 15:08.
Pushed by mqualmann into branch 'master'.

fix get most used people parent tag
Related: bug 395501
FIXED-IN: 7.5.0

M  +2    -2    NEWS
M  +24   -8    core/libs/database/tags/facetags.cpp

https://invent.kde.org/graphics/digikam/commit/bf167894ccd12a406b9560b635640a923dc101d2