[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    Re: kabc.po
From:       Albert Astals Cid <aacid () kde ! org>
Date:       2012-11-29 22:04:28
Message-ID: 4385332.Z03RUybadH () xps
[Download RAW message or body]

El Dimecres, 28 de novembre de 2012, a les 22:54:37, Stelios va escriure:
> Hi,
> 
> "Locality" and "Region" in kdepimlibs/kabc.po as defined in address.cpp
> are translated in ways that are too abstract for the purpose of a postal
> address.
> One problem is that although "Region" is well-defined at least in Europe,
> the number of different types of input in "Locality"
> (city/town/district/village/hamlet or more)
> in a way contaminates "Region".
> If the user happens to hesitate for a moment while filling the former,
> he may become unsure as well while filling the latter.

As far as I know this is "abstract" on purpose, addressing varies a lot 
between regions of the world to be able of really having a one definition fits 
all solution.

You may went to pursue further improvements of this wording with the 
developers https://mail.kde.org/mailman/listinfo/kde-pim, I don't think there 
is much we can do from the pure translation side.

Cheers,
  Albert


> 
> Also it looks like the formatting templates
> do not have effect on the presentation of address fields
> and the address types that normally satisfy different criteria belong to a
> single list.
> 
> Examples:
> 
> 1.
> In locality the values: "Paris" and "Paris, Élysée" are equally valid.
> 
> 2.
> For typical addresses a p.o. box should be alternative to locality/region.
> 
> 3.
> There is no formatting for addresses that do not require street names.
> 
> 4.
> The fact that a region signifies a broader area than locality may not be
> clear to everybody.
> 
> 5.
> The address types domestic, international, postal, parcel are items of the
> same list.
> 
> Would it make a difference to insert additional
> formatting templates in order to solve some of the issues above,
> also to make the locality string more specific to the user's input
> and at the same time preserving some traditional dependencies between
> fields?
> 
> Perhaps by combining formatting templates
> with reverse geocoding will improve things.
> According to a relevant article
> https://lwn.net/Articles/436937/
> there are some ongoing efforts.
> A wikipedia article reports that reverse geocoding may raise privacy
> concerns,
> but we're talking about publicly available data, isn't that so?
> 
> Also as a temporal fix, would it be useful
> to have either some lines of text near each field
> or mouse-hover tooltips to guide the user showing that
> e.g.
> a region is broader than locality
> user input for locality may or may not include a city-district combination,
> etc.?
> 
> regards,
> Stelios
[prev in list] [next in list] [prev in thread] [next in thread]