Allowing multilingual contact info would be a backwards-compatible change for information producers, but not for information consumers: since the additional attributes or elements would be optional, every IATI file that is valid before the change will be valid after; however, as David  Carpenter mentioned, as with any optional change, systems that process IATI data might be thrown off when the new elements appear.

We have two choices.  The first is to repeat the entire contact-info container for each language:

<contact-info xml:lang="en">
  <person-name>Yohanna Loucheur</person-name>
  <organisation>Canadian International Development Agency (CIDA)</organisation>
</contact-info>

<contact-info xml:lang="fr">
  <person-name>Yohanna Loucheur</person-name>
  <organisation>Agence canadienne de développement international</organisation>
</contact-info>

The other is to  repeat only the necessary fields for each language:

<contact-info>
  <person-name>Yohanna Loucheur</person-name>
  <organisation xml:lang="en">Canadian International Development Agency (CIDA)</organisation>
  <organisation xml:lang="fr">Agence canadienne de développement international (ACDI)</organisation>
</contact-info>

I'm not sure I understand the justification here.

Contact details are essential to the feedback loop built on top of IATI, and are not personal details. They are essential public contact information.

Can this be put forward for wider discussion for the next decimal upgrade.

I agree, Yohanna.  For example, many people from India and China use different names in English or French than they do in their own languages, so we can't even assume that person-name might not need to be translated.

asd

We agree - it would be useful to allow all elements of the IATI Standard to be published in multiple languages. The second option seems preferable to avoid repeating unnecessary information, while at the same time allowing information to be published in a different language where appropriate.

I agree with Tim, and I think this meets the definition of a decimal upgrade.

Whether or not publishers choose to publish personal information (and the department and job title is surely less personal than someone's name, as is permitted in the Standard at the moment), is surely a choice for the publishers. Including it in the Standard would not force the release of anything, and would not enable the release of more personal information than is possible at the moment. It would give publishers a choice that is somewhere between an indiivdual's name and a generic contact point.

I think it would be good for this proposal to go through and be discussed as part of the general consultation process, where these concerns could be raised and discussed.

We have added the following:

• Contact Type (with an associated code list)
• Job Title
• Website

The ability to report multiple languages has been added to:

• Organisation Name
• Person Name
• Job Title
• Mailing Address

Agree. There is no problem with adding this additional information and making it optional.

We are concerned that there may need to be wider consultation on what elements are required, so would welcome some more concrete proposals. It may be that this should be tried as an additional namespace, but if we can get it right quickly it could be part of the 1.03 release.

Looking at the 1.03 dev schema it looks to me as though:

1) Job title has been added, but Contact Type and Website have not

Also it seems that the elements are all of 'plainType' I think they should have been changed to 'textType' to enable multiple languages to be used as discussed above.

This is all fixed up now. Website is a new element, type is an attribute, language options are allowed.

I want to start drawing up schema code to represent this change in the next few days - is there agreement on this? Do we want more/less fields? Are we happy with backwards compatibility etc?

Re Added: We should consider including 'corruption report' on the code list. For example, the TAKUKURU operate a corruption reporting hot line (http://www.pccb.go.tz/) and providing a way for this information to be distributed within the ICT data would seem appropriate.

CIDA is fine with the proposal above as long as the fields are optional.

We had also submitted a request to the TAG to allow the use of different languages for Activity Contact. The Canadian government is legally required to publish in 2 languages (French and English). Other publishers may be in a similar position. Currently, CIDA is concatenating the French and English acronyms for "organisation name" (ACDI-CIDA) and publishing the address in English, which is really not ideal. Having separate fields with the language clearly identified would allow users to chose the language that best suit their needs.

To make it possible to publish in more than one language, we propose that the fields should have their own "language" tag (to identify the language of the field content) and a 0..n relation with the parent. 

In the Canadian case this would be required at least for the "organisation name" field and the "mailing address" field (mailing addresses are expressed differently depending on the language). However, it may be prudent to apply to all fields to accomodate others' needs.  

Hi Yohanna

To be honest I'm not clear. 

I think what is clear, is that where the standard deliberately made provision for alternative languages to be used, the method was to duplicate elements and to specify a default language on an activity and then an alternate language by using the xml:lang attribute. Those elements are designated as 'textType'

So it seems to me that we would need to change the contact-info elements to be of type 'textType' to do things 'the standard way'

I'm also seeking clarification about 'plainType', my reading is that the use of xml:lang is not forbidden (extended attributes may be used) but crucially people using the data will not expect to see it, and therefore will not expect to see those elements in different languages.

So, if those elements were treated as 'textType's where we could use xml:lang - would that be a suitable solution for you? (I'm not sure whether or not this would count as a backwards compatible change tho.)

Thanks for engaging in this.

There may be a problem with the contact-info fields at the moment as they are designated as 'plainText' type. We usually use 'textType' to enable an element to specified in more than one language.

The current approach to language is to have duplicate elements with the xml:lang= "" attribute designating the language of the supplied text. I'm unclear as to whether or not that is sufficient for what is being asked here. Will try to clarify.

Just to confirm that we believe we would need to change the contact-info elements (and sub-elements) to become 'textType' instead of 'plainType', as well as add the new sub-elements.

We should consider including 'corruption report' on the code list. For example, the World Bank operate a corruption reporting hot line (http://web.worldbank.org/WBSITE/EXTERNAL/EXTABOUTUS/ORGANIZATION/ORGUNITS/EXTDOII/0,,contentMDK:20659616~menuPK:1702202~pagePK:64168445~piPK:64168309~theSitePK:588921,00.html) and providing a way for this information to be distributed within the IATI data would seem appropriate.

Thanks David for these suggestions.  We tend to prefer the second option to avoid repeating unecessary information.  Let's make sure we allow this change for all the elements of Contact-Info, as we don't know which elements some publishers may wish to publish in more that one language.

There seems to be a move towards providing less personal data in IATI, so this proposal is not to be carried forward for our first decimal upgrade.