Menu
▾
▴
opensync-devel
|
From: HIRANO T. <hir...@zn...> - 2009-06-14 15:27:33
|
Hello, I have a question on how to add alternative names to a person in OpenSync. We would often like to add alternative names to a person. For example, a Chinese person has their name in Chinese characters, but non-Chinese speakers may want to have his/her name in Latin characters in addition to that. However, this XML schema: http://svn.opensync.org/format-plugins/xmlformat/trunk/schemas/xmlformat-contact.xsd says that the Name element can occur only once in a Contact element. Because of this, we cannot have multiple names for a person. This is especially important in Japan. Japanese people always use two formats for their names: kanji and furigana (or yomigana). So I need to investigate how to store them. I think there are several ways to do this: 1) Allow multiple Name elements in a Contact element in the XML schema 2) Introduce AlternativeName (generic) or Furigana (specific to Japan) element to the XML schema 3) Store alternative name in FormattedName using parentheses, like "Latin Characters (Chinese Characters)" or "Furigana (Kanji)" 3) does not require any change for OpenSync. But it is non-standard and it will cause compatibility problem between plugins. Regards, HIRANO Takahito |
|
From: Daniel G. <go...@b1...> - 2009-06-14 15:35:54
|
On Sunday 14 June 2009 05:25:55 pm HIRANO Takahito wrote: [...] > This is especially important in Japan. > Japanese people always use two formats for their names: kanji and > furigana (or yomigana). > So I need to investigate how to store them. > > I think there are several ways to do this: > 1) Allow multiple Name elements in a Contact element in the XML schema > 2) Introduce AlternativeName (generic) or Furigana (specific to Japan) > element to the XML schema > 3) Store alternative name in FormattedName using parentheses, like > "Latin Characters (Chinese Characters)" or "Furigana (Kanji)" > > 3) does not require any change for OpenSync. > But it is non-standard and it will cause compatibility problem between > plugins. How is this handled inside VCARDs? Do you have more examples from other plugins/formats how this is handled? Best Regards, Daniel -- Daniel Gollub Geschaeftsfuehrer: Ralph Dehner FOSS Developer Unternehmenssitz: Vohburg B1 Systems GmbH Amtsgericht: Ingolstadt Mobil: +49-(0)-160 47 73 970 Handelsregister: HRB 3537 EMail: go...@b1... http://www.b1-systems.de Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D |
|
From: HIRANO T. <hir...@zn...> - 2009-06-14 15:49:52
|
(Sorry, I forgot Cc.) Thank you for your quick reply! In VCARD, there are no standards on how to store alternative names, but some applications store them in SORT-STRING. SynCE plugin handles alternative name internally as YomiCompanyName (furigana of a company name), YomiFirstName (furigana of a first name), YomiLastName (furigana of a last name). See: http://synce.svn.sourceforge.net/viewvc/synce/trunk/sync-engine/SyncEngine/wbxml/dtd.py?view=markup 2009/6/15 Daniel Gollub <go...@b1...>: > On Sunday 14 June 2009 05:25:55 pm HIRANO Takahito wrote: > [...] >> This is especially important in Japan. >> Japanese people always use two formats for their names: kanji and >> furigana (or yomigana). >> So I need to investigate how to store them. >> >> I think there are several ways to do this: >> 1) Allow multiple Name elements in a Contact element in the XML schema >> 2) Introduce AlternativeName (generic) or Furigana (specific to Japan) >> element to the XML schema >> 3) Store alternative name in FormattedName using parentheses, like >> "Latin Characters (Chinese Characters)" or "Furigana (Kanji)" >> >> 3) does not require any change for OpenSync. >> But it is non-standard and it will cause compatibility problem between >> plugins. > > How is this handled inside VCARDs? > Do you have more examples from other plugins/formats how this is handled? > > Best Regards, > Daniel > > -- > Daniel Gollub Geschaeftsfuehrer: Ralph Dehner > FOSS Developer Unternehmenssitz: Vohburg > B1 Systems GmbH Amtsgericht: Ingolstadt > Mobil: +49-(0)-160 47 73 970 Handelsregister: HRB 3537 > EMail: go...@b1... http://www.b1-systems.de > > Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg > http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D > |
|
From: Daniel G. <go...@b1...> - 2009-06-14 17:55:21
|
On Sunday 14 June 2009 05:49:47 pm HIRANO Takahito wrote: > (Sorry, I forgot Cc.) > > Thank you for your quick reply! > > In VCARD, there are no standards on how to store alternative names, > but some applications store them in SORT-STRING. Ok, i see. I asked this question to try to honor existing standards. > > SynCE plugin handles alternative name internally as YomiCompanyName > (furigana of a company name), YomiFirstName (furigana of a first > name), YomiLastName (furigana of a last name). > See: > http://synce.svn.sourceforge.net/viewvc/synce/trunk/sync-engine/SyncEngine/ >wbxml/dtd.py?view=markup Thanks for this pointer. Best Regards, Daniel -- Daniel Gollub Geschaeftsfuehrer: Ralph Dehner FOSS Developer Unternehmenssitz: Vohburg B1 Systems GmbH Amtsgericht: Ingolstadt Mobil: +49-(0)-160 47 73 970 Handelsregister: HRB 3537 EMail: go...@b1... http://www.b1-systems.de Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D |
|
From: HIRANO T. <hir...@zn...> - 2009-06-15 02:08:51
|
I consulted the vCard format used by iPhone and Android. They seem to use X-PHONETIC-FIRST-NAME, X-PHONETIC-LAST-NAME instead of SORT-STRING, which has been used by Japanese classic cell phones. I think it would be better for OpenSync to use these fields. 2009/6/15 HIRANO Takahito <hir...@zn...>: > (Sorry, I forgot Cc.) > > Thank you for your quick reply! > > In VCARD, there are no standards on how to store alternative names, > but some applications store them in SORT-STRING. > > SynCE plugin handles alternative name internally as YomiCompanyName > (furigana of a company name), YomiFirstName (furigana of a first > name), YomiLastName (furigana of a last name). > See: > http://synce.svn.sourceforge.net/viewvc/synce/trunk/sync-engine/SyncEngine/wbxml/dtd.py?view=markup > > 2009/6/15 Daniel Gollub <go...@b1...>: >> On Sunday 14 June 2009 05:25:55 pm HIRANO Takahito wrote: >> [...] >>> This is especially important in Japan. >>> Japanese people always use two formats for their names: kanji and >>> furigana (or yomigana). >>> So I need to investigate how to store them. >>> >>> I think there are several ways to do this: >>> 1) Allow multiple Name elements in a Contact element in the XML schema >>> 2) Introduce AlternativeName (generic) or Furigana (specific to Japan) >>> element to the XML schema >>> 3) Store alternative name in FormattedName using parentheses, like >>> "Latin Characters (Chinese Characters)" or "Furigana (Kanji)" >>> >>> 3) does not require any change for OpenSync. >>> But it is non-standard and it will cause compatibility problem between >>> plugins. >> >> How is this handled inside VCARDs? >> Do you have more examples from other plugins/formats how this is handled? >> >> Best Regards, >> Daniel >> >> -- >> Daniel Gollub Geschaeftsfuehrer: Ralph Dehner >> FOSS Developer Unternehmenssitz: Vohburg >> B1 Systems GmbH Amtsgericht: Ingolstadt >> Mobil: +49-(0)-160 47 73 970 Handelsregister: HRB 3537 >> EMail: go...@b1... http://www.b1-systems.de >> >> Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg >> http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D >> > |
|
From: Juha T. <Juh...@ik...> - 2009-06-14 16:06:36
|
On Sunday 14 June 2009 18:35:44 Daniel Gollub wrote: > On Sunday 14 June 2009 05:25:55 pm HIRANO Takahito wrote: > How is this handled inside VCARDs? > Do you have more examples from other plugins/formats how this is handled? I don't think opensync should be limited by the limited specification of vcards. kaddressbook is a good example of this, it's a program built around those specifications, when it should be rather fullfeatured program being able to *export* related information to vcard as far as that vcard is able to carry that information. Tuju -- Better to have one, and not need it, than to need one and not have it. |
|
From: Juha T. <Juh...@ik...> - 2009-06-14 16:11:48
|
On Sunday 14 June 2009 18:49:47 HIRANO Takahito wrote: > In VCARD, there are no standards on how to store alternative names, > but some applications store them in SORT-STRING. How about you start an X-NAME;TYPE=furigana:Foo Bar de facto standard? :) Tuju -- Better to have one, and not need it, than to need one and not have it. |
|
From: Daniel G. <go...@b1...> - 2009-06-14 17:56:35
|
On Sunday 14 June 2009 06:11:37 pm Juha Tuomala wrote: > On Sunday 14 June 2009 18:49:47 HIRANO Takahito wrote: > > In VCARD, there are no standards on how to store alternative names, > > but some applications store them in SORT-STRING. > > How about you start an > > X-NAME;TYPE=furigana:Foo Bar > > de facto standard? :) Which device/application is using this? Best Regards, Daniel -- Daniel Gollub Geschaeftsfuehrer: Ralph Dehner FOSS Developer Unternehmenssitz: Vohburg B1 Systems GmbH Amtsgericht: Ingolstadt Mobil: +49-(0)-160 47 73 970 Handelsregister: HRB 3537 EMail: go...@b1... http://www.b1-systems.de Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D |
|
From: Daniel G. <go...@b1...> - 2009-06-14 17:58:43
|
On Sunday 14 June 2009 06:06:28 pm Juha Tuomala wrote: > On Sunday 14 June 2009 18:35:44 Daniel Gollub wrote: > > On Sunday 14 June 2009 05:25:55 pm HIRANO Takahito wrote: > > How is this handled inside VCARDs? > > Do you have more examples from other plugins/formats how this is handled? > > I don't think opensync should be limited by the limited > specification of vcards. Right. But xmlformat-contact is based on the vcard 3.0 Standard. > kaddressbook is a good example of this, it's a program built > around those specifications, when it should be rather fullfeatured > program being able to *export* related information to vcard as > far as that vcard is able to carry that information. Right. Just wanted to check how this is implemented in already exisiting devices/specification. So we find the best fitting solution for this. Juha, how would you handle this in the xmlformat-contact schema? Best Regards, Daniel -- Daniel Gollub Geschaeftsfuehrer: Ralph Dehner FOSS Developer Unternehmenssitz: Vohburg B1 Systems GmbH Amtsgericht: Ingolstadt Mobil: +49-(0)-160 47 73 970 Handelsregister: HRB 3537 EMail: go...@b1... http://www.b1-systems.de Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D |
|
From: Juha T. <Juh...@ik...> - 2009-06-14 18:47:29
|
On Sunday 14 June 2009 20:58:30 you wrote: > On Sunday 14 June 2009 06:06:28 pm Juha Tuomala wrote: > > kaddressbook is a good example of this, it's a program built > > around those specifications, when it should be rather fullfeatured > > program being able to *export* related information to vcard as > > far as that vcard is able to carry that information. > > Right. > > Just wanted to check how this is implemented in already exisiting > devices/specification. So we find the best fitting solution for this. > > Juha, how would you handle this in the xmlformat-contact schema? I always understood that xmlformat is opensync internal format, vformat is the interface to these v* formats. If that's true, then the vcard compatibility and stripping the non-standard stuff should fall into vformat plugin, right? And what xmlformat is able to carry, is only limited by developer imagination or real world needs of opensync. Tuju -- Better to have one, and not need it, than to need one and not have it. |
Thanks for helping keep SourceForge clean.
X