Hi, a few things I encountered / remembered just now (currently with 0.11rc1):
- At the periodic sync update (the default 60 seconds for me) the entire webpage goes void of data (the frames are still there, but address books and contacts disappear) for a few seconds, then all goes back to normal. However, it does jump back to the first contact in the address book and if I was editing a contact, the light-grey "edit mode" of the list persists, so I cannot click on other contacts unless I either log in and back out or click "edit" on the displayed contact then cancel. If there was unsaved data in the edited contact it is of course lost after this. There are no error messages in the console. I don't remember this happening before - CalDavZAP for instance still syncs very nicely in the background, all I see is the little rotating symbol.
- You might want to include special Romanian chars U+015E, U+015F (s with cedilla) and U+0162, U+0163 (t with cedilla) in the sort and search alphabet strings at letter 's' and 't' respectively - I can do it in my own config but I guess it doesn't hurt to have them there by default. You might also want to include U+218, U+219 (s with comma) and U+21A, U+21B (t with comma) versions too - only one of these two version is actually supposed to exist, but which one is the correct one is a rather messy affair - interested parties can read all about it at [1] (TL;DR: cedilla is the widely supported and used one, comma is supposed to be the correct one).
- Currently the address format for contacts in Romania hides the "county" field which is a very much existing, valid and used field (as also supported by [2] and [3]) called "Judet". Personally, the layout I use for "addressTypes['ro']" in "common.js" is 2 : street, 5 : code, 6 : locality, 9 : region (county), 11 : country but I guess the exact layout / order is a matter of some debate as well - even [2] and [3] contradict each other on this. To be honest, I also use the same field on Hungarian addresses as well ("Megye"), but official addressing samples don't seem to support me on this so I'm not particularly pushing for that.
Regards, - Attila
[1] - http://en.wikipedia.org/wiki/Romanian_alphabet#Comma-below_.28.C8.99_and_.C8... [2] - http://en.wikipedia.org/wiki/Mailing_address_format_by_country#Romania [3] - http://www.posta-romana.ro/posta-romana/produse-si-servicii/Personal_subpagi...
Hi Atilla,
On Mar 14, 2013, at 8:23 PM, Attila Asztalos attila.asztalos@gmail.com wrote:
Hi, a few things I encountered / remembered just now (currently with 0.11rc1):
- At the periodic sync update (the default 60 seconds for me) the entire webpage goes void of data (the frames are still there, but address books and contacts disappear) for a few seconds, then all goes back to normal. However, it does jump back to the first contact in the address book and if I was editing a contact, the light-grey "edit mode" of the list persists, so I cannot click on other contacts unless I either log in and back out or click "edit" on the displayed contact then cancel. If there was unsaved data in the edited contact it is of course lost after this. There are no error messages in the console. I don't remember this happening before - CalDavZAP for instance still syncs very nicely in the background, all I see is the little rotating symbol.
will check, it is very probably caused by bug in full-sync (this release contains major changes in this functionality)
- You might want to include special Romanian chars U+015E, U+015F (s with cedilla) and U+0162, U+0163 (t with cedilla) in the sort and search alphabet strings at letter 's' and 't' respectively - I can do it in my own config but I guess it doesn't hurt to have them there by default. You might also want to include U+218, U+219 (s with comma) and U+21A, U+21B (t with comma) versions too - only one of these two version is actually supposed to exist, but which one is the correct one is a rather messy affair - interested parties can read all about it at [1] (TL;DR: cedilla is the widely supported and used one, comma is supposed to be the correct one).
will add
- Currently the address format for contacts in Romania hides the "county" field which is a very much existing, valid and used field (as also supported by [2] and [3]) called "Judet". Personally, the layout I use for "addressTypes['ro']" in "common.js" is 2 : street, 5 : code, 6 : locality, 9 : region (county), 11 : country but I guess the exact layout / order is a matter of some debate as well - even [2] and [3] contradict each other on this. To be honest, I also use the same field on Hungarian addresses as well ("Megye"), but official addressing samples don't seem to support me on this so I'm not particularly pushing for that.
hmm .. the problem is, that I want to be compatible with Contacts.app in OS X and iOS - so I use the same fields as Apple (our setup = 50 users with iPhone /+ few with iPad/)
JM
Regards,
- Attila
[1] - http://en.wikipedia.org/wiki/Romanian_alphabet#Comma-below_.28.C8.99_and_.C8... [2] - http://en.wikipedia.org/wiki/Mailing_address_format_by_country#Romania [3] - http://www.posta-romana.ro/posta-romana/produse-si-servicii/Personal_subpagi...
Hi Ján,
On 14-Mar-2013 22:24, Ján Máté wrote:
On Mar 14, 2013, at 8:23 PM, Attila Asztalos attila.asztalos@gmail.com wrote:
- Currently the address format for contacts in Romania hides the "county" field which is a very much existing, valid and used field (as also supported by [2] and [3]) called "Judet". Personally, the layout I use for "addressTypes['ro']" in "common.js" is 2 : street, 5 : code, 6 : locality, 9 : region (county), 11 : country but I guess the exact layout / order is a matter of some debate as well - even [2] and [3] contradict each other on this. To be honest, I also use the same field on Hungarian addresses as well ("Megye"), but official addressing samples don't seem to support me on this so I'm not particularly pushing for that.
hmm .. the problem is, that I want to be compatible with Contacts.app in OS X and iOS - so I use the same fields as Apple (our setup = 50 users with iPhone /+ few with iPad/)
Interesting... does that mean that on iOS there is no field for "county" at all when entering a Romanian address (I suppose there has to be a "county" field for at least, say, US addresses - and it's that field I use, not some custom one)...?
- Attila
Hi,
iOS uses the same approach as CardDavMATE => show only relevant fields for the selected country:
Romania in iOS looks like:
Street Postal Code City Romania
for other countries there are other fields ... for example, US looks like:
Street City State ZIP United States
JM
On Mar 14, 2013, at 10:29 PM, Attila Asztalos attila.asztalos@gmail.com wrote:
Hi Ján,
On 14-Mar-2013 22:24, Ján Máté wrote:
On Mar 14, 2013, at 8:23 PM, Attila Asztalos attila.asztalos@gmail.com wrote:
- Currently the address format for contacts in Romania hides the "county" field which is a very much existing, valid and used field (as also supported by [2] and [3]) called "Judet". Personally, the layout I use for "addressTypes['ro']" in "common.js" is 2 : street, 5 : code, 6 : locality, 9 : region (county), 11 : country but I guess the exact layout / order is a matter of some debate as well - even [2] and [3] contradict each other on this. To be honest, I also use the same field on Hungarian addresses as well ("Megye"), but official addressing samples don't seem to support me on this so I'm not particularly pushing for that.
hmm .. the problem is, that I want to be compatible with Contacts.app in OS X and iOS - so I use the same fields as Apple (our setup = 50 users with iPhone /+ few with iPad/)
Interesting... does that mean that on iOS there is no field for "county" at all when entering a Romanian address (I suppose there has to be a "county" field for at least, say, US addresses - and it's that field I use, not some custom one)...?
- Attila
Hi,
I see... really interesting. It is unfortunate then that Apple is misinformed about this. :) It's not a huge deal of course, I can keep a diff on this - but do you think this could possibly become influenced by, say, the "globalCompatibility" setting (which is also an "apple-or-something-else" thing) or something equivalent? As I said, it's not a huge problem if it can't though...
- Attila
On 14-Mar-2013 23:33, Ján Máté wrote:
Hi,
iOS uses the same approach as CardDavMATE => show only relevant fields for the selected country:
Romania in iOS looks like:
Street Postal Code City Romania
for other countries there are other fields ... for example, US looks like:
Street City State ZIP United States
JM
On Mar 14, 2013, at 10:29 PM, Attila Asztalos attila.asztalos@gmail.com wrote:
Hi Ján,
On 14-Mar-2013 22:24, Ján Máté wrote:
On Mar 14, 2013, at 8:23 PM, Attila Asztalos attila.asztalos@gmail.com wrote:
- Currently the address format for contacts in Romania hides the "county" field which is a very much existing, valid and used field (as also supported by [2] and [3]) called "Judet". Personally, the layout I use for "addressTypes['ro']" in "common.js" is 2 : street, 5 : code, 6 : locality, 9 : region (county), 11 : country but I guess the exact layout / order is a matter of some debate as well - even [2] and [3] contradict each other on this. To be honest, I also use the same field on Hungarian addresses as well ("Megye"), but official addressing samples don't seem to support me on this so I'm not particularly pushing for that.
hmm .. the problem is, that I want to be compatible with Contacts.app in OS X and iOS - so I use the same fields as Apple (our setup = 50 users with iPhone /+ few with iPad/)
Interesting... does that mean that on iOS there is no field for "county" at all when entering a Romanian address (I suppose there has to be a "county" field for at least, say, US addresses - and it's that field I use, not some custom one)...?
- Attila
I do not want to add compatibility setting for everything, because after few years I will have 50 compatibility options and then every change in the software will be a nightmare.
JM
On Mar 14, 2013, at 11:12 PM, Attila Asztalos attila.asztalos@gmail.com wrote:
Hi,
I see... really interesting. It is unfortunate then that Apple is misinformed about this. :) It's not a huge deal of course, I can keep a diff on this - but do you think this could possibly become influenced by, say, the "globalCompatibility" setting (which is also an "apple-or-something-else" thing) or something equivalent? As I said, it's not a huge problem if it can't though...
- Attila
-
Attila Asztalos -
Ján Máté