GNOME Bugzilla – Bug 636809
Address labels should be formated according to country specific standards
Last modified: 2011-06-02 16:48:43 UTC
Home and work address labels are formatted statically. However, different countries have different specific formattings of addresses. The netherlands for instance has <full name> <street no> <zipcode> <city> Formatting should be according to locale setting of the country and in case the country is given for an adress acording to that specific country settings. This requires a list of address formats per country. KDE already has such a setup for Kontact/Kaddressbook. Maybe this can be reused. I hope this bug can be resolved. Currently I'm stuck printing address labels using glabels and the evolution addressbook as input. The addresslabels are just wrong and I can't configure it.
Some background info. I try to migrate from Kaddressbook+kbarcode to Evolution+Glabel for printing address labels. This bug/feature request is keeping me from migrating fully. Regards, Bert Haverkamp
There is no workaround for this, I'm not aware of any, at least. This might be a nice job for Dan, I'm CCing him.
In KDE they have a file for each language where the format for address is specified. These files are part of KDE l10n and are maintained by respective translation teams. The question is: do we want something similar? My idea is to rather create a single file with simple map, something like ... cz=format_description de=format_description ... It does not really change much, so there's no need for evo translators to bother with this. The format descriptions are simple strings with printf-like specifiers. We can actually steal the strings from KDE, there are formats description for at least 26 countries.
Hi Dan, Thanks for taking up this request/bugreport. What you propose sounds exactly what I am looking for. One question: would the localised formatting of the address also make it into glabel? i dont know the mechanism used to move the info between evolution and glabel. Or does glabel neef to be changed as wel? Also, it might also be handy to also have a personal version of the format description, next to a systemwide version. Sometimes address formats are subject to taste.. For instance in KDE Canadian adresses are printed in CAPITALS for some reason. Being able to override that would be a plus.
I think you need to discuss this with GLabels developers. Contacts in Evolution are stored in vCard format which does not specify the address formatting, this will be done just before putting it on screen. I'd suggest to have an option in the menu to switch globally between format which is specific for you country (e.g. all addresses in you addressbook will be formatted according to your desktop localization) and format which will be derived from country given in the address (e.g. each address will be formatted according to it's the country). Btw the Canadian addresses are in capital, because it's official Canada Post format :)
Created attachment 183979 [details] [review] Local address formatting patch This patch formats address to local format (format of the country the address aims to). It uses two files - address_formats.dat, which is .ini-like file with address formats for each country (covers about 30 countries atm) and countrytransl.map (taken from kdepimlibs) which contains translated names of countries and their ISO codes. These two files have totally about 6000 lines and are included in following patch separated from the code. The code itself just finds ISO code for country listed in address, then finds an address format for the ISO it retrieved and finally does some search'n'replace. Consider this rather preview then final code, I'm not sure, how much it is ready-to-go :)
Created attachment 183980 [details] [review] Locale address formatting databases The databases for address formatting. It's quite huge (cca 6k lines) and it would be nice if some translators could take a look on it and maybe expand the countrytransl.map file. These files are installed to /usr/share/evolution/%version/.
Created attachment 187614 [details] [review] Fixed and improved patch This is an improved and fixed version of previous patch. I dropped GRegex for better performance and fix various memory leaks within the code.
Comment on attachment 187614 [details] [review] Fixed and improved patch We had a session with Dan where I expressed my concerns about this patch. I do not have exact notes on this, Dan has, but I'm marking the patch status accordingly, to avoid re-review for others.
Created attachment 188116 [details] [review] Reworked patch This patch addresses the issues we discussed with Milan: - completely reworked replacing algorithm - the template fromat is now processed lineary, so there's no danger of accidentally expanding user's "%X" in already expanded strings - moved everything to eab-gui-utils.c - renamed format_address to eab_format_address - show warning when a database file does not exist/can't be opened - fixed various coding style issues - minimized number of allocations - merged get_home_address_format() and get_business_address_format() to get_address_format() - improved working with locale string - better handling of NULLs - using %m instead of %cm - using %\n instead of \n - using const properly + a minor memory leak fix in eab-contact-display.c
Created attachment 188117 [details] [review] Updated databases Updated address_formats.dat database: - using %m instead of %cm - using %\n instead of \n
Thanks for the update. I gave it a try and it seems to work, even I see that the database of country names will need a bit of expansion, it may know iso country codes, for example, and for "czech republic" it seems to know only "Česko", where I use to write "Česká republika", some people maybe also "CZ", "CR" or ČR (the longest part is usually the mostly used in the country itself, though). But that's question for other people to populate it based on their usage. I've couple last notes on the patch, and then it'll be ready to commit: a) you forgot to return the 'label' part in the accum_address function, because that's the place where people can write their preferred format of the address. b) get_locales() can return NULL, thus let's be a bit more paranoid, as you expect always getting at least two items in the array. c) when calling get_address_format() recursively, make sure you'll fallback only on the value you want to fallback, not on both. d) g_string_append_upper(), "!c && !*c" is always false or crashing, isn't it? e) I would rename g_string_append_upper(), it's not part of glib, thus do not pretend it is f) really minor thing: add spaces around arithmetic like here: (bpos2-bpos1+2) Otherwise looks good, much nicer code than the initial one. Thanks for it.
Created attachment 188910 [details] [review] Updated patch Here is updated patch. After discussion with Milan we decided not to display the formatted address in preview, but to save the formatted address to VCard's LABEL field, so that it is already formatted when displaying + when the VCard is exported, the address remains formatted too. Therefor there are no changes in EABContactDisplay anymore (except for minor memory leak fix), but the changes went to EContactEditor. The other issues Milan mentioned in his comment above are resolved by this patch too (I just hope I haven't miss any formatting issue :)
Created attachment 188911 [details] [review] Updated database Once more, due to changes mentioned above I had to update format of the address formats database. The newline characters are no longer tokens (%\n) but just newlines (\n) since we don't need to replace the newline characters with <br> when storing the formatted address to VCard instead of displaying it (EABContactDisplay takes care of that).
Looks good. After really minor changes I committed the patches into master. Created commit 171b6f6 in evo master (3.1.2+)