(Maybe) incorrect GUI message ("Supplication")

[Luigi Toscano]

Hi all,
the Digikam Italian translator found a string which he thinks (and I agree)
that should be fixed. The string lives here:
https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/libs/template/templatepanel.cpp#L263

The word "Supplication" was introduced in place of the previous "Sublocations"
(referenced by the rest of the code) here:
http://websvn.kde.org/trunk/extragear/graphics/digikam/libs/template/templatepanel.cpp?r1=1179448&r2=1179447&pathrev=1179448

The question is: is the analysis correct, and should the old term be restored?
I can do it, in case. Even if the old term is not the correct one, I think
that the current word it's not the best fit.


Ciao
--
Luigi

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Andrew Goodbody]

Well 'Supplication' is definitely very wrong. However I do not like
'Sublocation' either; although I could not say that it is wrong, it is
quite a long way from the best word to use. Unfortunately I suspect that
the best word to use may vary according to local usage. It is not clear
to me from that code if it refers to something smaller than a city or
larger than a city. So 'Sublocation' may be an attempt at compromise but
to me it is a compromise that suits no one. I would tentatively suggest
'District' but I may be trying to give a name to something that does not
exist in my understanding.

Andrew

On 01/03/15 16:19, Luigi Toscano wrote:

> Hi all,
> the Digikam Italian translator found a string which he thinks (and I agree)
> that should be fixed. The string lives here:
> https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/libs/template/templatepanel.cpp#L263
>
> The word "Supplication" was introduced in place of the previous "Sublocations"
> (referenced by the rest of the code) here:
> http://websvn.kde.org/trunk/extragear/graphics/digikam/libs/template/templatepanel.cpp?r1=1179448&r2=1179447&pathrev=1179448
>
> The question is: is the analysis correct, and should the old term be restored?
> I can do it, in case. Even if the old term is not the correct one, I think
> that the current word it's not the best fit.
>
>
> Ciao
>

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Luigi Toscano]

Andrew Goodbody ha scritto:
> Well 'Supplication' is definitely very wrong. However I do not like
> 'Sublocation' either; although I could not say that it is wrong, it is quite a
> long way from the best word to use. Unfortunately I suspect that the best word
> to use may vary according to local usage. It is not clear to me from that code
> if it refers to something smaller than a city or larger than a city.

Sorry for the late answer. It seems that the naming is related to the IPTC
specifications, where "sublocation" is described as:
"Name of a sublocation the content is focussing on -- either the location
shown in visual media or referenced by text or audio media. This location name
could either be the name of a sublocatioto a city or the name of a well known
location or (natural) monument outside a city. In the sense of a sublocation
to a city this element is at the fourth level of a top-down geographical
hierarchy"

So smaller that a city, a specific place.

See: http://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata ,
page 18.

(Luckily it has been replaced by two other keys, "Location Created" and
"Location Shown").


>
> So 'Sublocation' may be an attempt at compromise but to me it is a compromise
> that suits no one. I would tentatively suggest 'District' but I may be trying
> to give a name to something that does not exist in my understanding.

So no District for sure. Given that this is the official name of a tag, I
would leave Sublocation. If you agree, I can push the change myself: which
branches?

Ciao
--
Luigi
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2015-03-15 19:13 GMT+01:00 Luigi Toscano <[hidden email]>:

> Andrew Goodbody ha scritto:
>> Well 'Supplication' is definitely very wrong. However I do not like
>> 'Sublocation' either; although I could not say that it is wrong, it is quite a
>> long way from the best word to use. Unfortunately I suspect that the best word
>> to use may vary according to local usage. It is not clear to me from that code
>> if it refers to something smaller than a city or larger than a city.
>
> Sorry for the late answer. It seems that the naming is related to the IPTC
> specifications, where "sublocation" is described as:
> "Name of a sublocation the content is focussing on -- either the location
> shown in visual media or referenced by text or audio media. This location name
> could either be the name of a sublocatioto a city or the name of a well known
> location or (natural) monument outside a city. In the sense of a sublocation
> to a city this element is at the fourth level of a top-down geographical
> hierarchy"
>
> So smaller that a city, a specific place.
>
> See: http://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata ,
> page 18.
>
> (Luckily it has been replaced by two other keys, "Location Created" and
> "Location Shown").
>
>
>>
>> So 'Sublocation' may be an attempt at compromise but to me it is a compromise
>> that suits no one. I would tentatively suggest 'District' but I may be trying
>> to give a name to something that does not exist in my understanding.
>
> So no District for sure. Given that this is the official name of a tag, I
> would leave Sublocation. If you agree, I can push the change myself: which
> branches?

git master and frameworks branches must be patched...

Gilles Caulier
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Luigi Toscano]

Gilles Caulier ha scritto:

> 2015-03-15 19:13 GMT+01:00 Luigi Toscano <[hidden email]>:
>> Andrew Goodbody ha scritto:
>>> Well 'Supplication' is definitely very wrong. However I do not like
>>> 'Sublocation' either; although I could not say that it is wrong, it is quite a
>>> long way from the best word to use. Unfortunately I suspect that the best word
>>> to use may vary according to local usage. It is not clear to me from that code
>>> if it refers to something smaller than a city or larger than a city.
>>
>> Sorry for the late answer. It seems that the naming is related to the IPTC
>> specifications, where "sublocation" is described as:
>> "Name of a sublocation the content is focussing on -- either the location
>> shown in visual media or referenced by text or audio media. This location name
>> could either be the name of a sublocatioto a city or the name of a well known
>> location or (natural) monument outside a city. In the sense of a sublocation
>> to a city this element is at the fourth level of a top-down geographical
>> hierarchy"
>>
>> So smaller that a city, a specific place.
>>
>> See: http://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata ,
>> page 18.
>>
>> (Luckily it has been replaced by two other keys, "Location Created" and
>> "Location Shown").
>>
>>
>>>
>>> So 'Sublocation' may be an attempt at compromise but to me it is a compromise
>>> that suits no one. I would tentatively suggest 'District' but I may be trying
>>> to give a name to something that does not exist in my understanding.
>>
>> So no District for sure. Given that this is the official name of a tag, I
>> would leave Sublocation. If you agree, I can push the change myself: which
>> branches?
>
> git master and frameworks branches must be patched...

Thanks.
Should I commit the change separately in the two branches, or do you regularly
merge master in frameworks as it happens in other projects (so that I need to
fix it in master only)?

Ciao
--
Luigi

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Andrew Goodbody]

On 15/03/15 18:13, Luigi Toscano wrote:

> So smaller that a city, a specific place.
>
> See: http://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata ,
> page 18.
>
> (Luckily it has been replaced by two other keys, "Location Created" and
> "Location Shown").
>
>> So 'Sublocation' may be an attempt at compromise but to me it is a compromise
>> that suits no one. I would tentatively suggest 'District' but I may be trying
>> to give a name to something that does not exist in my understanding.
>
> So no District for sure. Given that this is the official name of a tag, I
> would leave Sublocation. If you agree, I can push the change myself: which
> branches?

OK, so it is referencing a term in another specification, then I have no
objection to it.

Andrew
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

branches must be synchronized by hand. There is too many differences now.

Gilles Caulier

2015-03-15 22:36 GMT+01:00 Luigi Toscano <[hidden email]>:

> Gilles Caulier ha scritto:
>> 2015-03-15 19:13 GMT+01:00 Luigi Toscano <[hidden email]>:
>>> Andrew Goodbody ha scritto:
>>>> Well 'Supplication' is definitely very wrong. However I do not like
>>>> 'Sublocation' either; although I could not say that it is wrong, it is quite a
>>>> long way from the best word to use. Unfortunately I suspect that the best word
>>>> to use may vary according to local usage. It is not clear to me from that code
>>>> if it refers to something smaller than a city or larger than a city.
>>>
>>> Sorry for the late answer. It seems that the naming is related to the IPTC
>>> specifications, where "sublocation" is described as:
>>> "Name of a sublocation the content is focussing on -- either the location
>>> shown in visual media or referenced by text or audio media. This location name
>>> could either be the name of a sublocatioto a city or the name of a well known
>>> location or (natural) monument outside a city. In the sense of a sublocation
>>> to a city this element is at the fourth level of a top-down geographical
>>> hierarchy"
>>>
>>> So smaller that a city, a specific place.
>>>
>>> See: http://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata ,
>>> page 18.
>>>
>>> (Luckily it has been replaced by two other keys, "Location Created" and
>>> "Location Shown").
>>>
>>>
>>>>
>>>> So 'Sublocation' may be an attempt at compromise but to me it is a compromise
>>>> that suits no one. I would tentatively suggest 'District' but I may be trying
>>>> to give a name to something that does not exist in my understanding.
>>>
>>> So no District for sure. Given that this is the official name of a tag, I
>>> would leave Sublocation. If you agree, I can push the change myself: which
>>> branches?
>>
>> git master and frameworks branches must be patched...
>
> Thanks.
> Should I commit the change separately in the two branches, or do you regularly
> merge master in frameworks as it happens in other projects (so that I need to
> fix it in master only)?
>
> Ciao
> --
> Luigi
>
> _______________________________________________
> Digikam-devel mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-devel

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Luigi Toscano]

Gilles Caulier ha scritto:
> branches must be synchronized by hand. There is too many differences now.
>

It's never too late for a merge :)

Anyway, I will cherry-pick in frameworks.

Ciao
--
Luigi

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

Thanks

Gilles

2015-03-15 23:10 GMT+01:00 Luigi Toscano <[hidden email]>:

> Gilles Caulier ha scritto:
>> branches must be synchronized by hand. There is too many differences now.
>>
>
> It's never too late for a merge :)
>
> Anyway, I will cherry-pick in frameworks.
>
> Ciao
> --
> Luigi
>
> _______________________________________________
> Digikam-devel mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-devel

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel