Configure the date format in the Curriculums

139 views
Skip to first unread message

admilso...@gmail.com

unread,
Apr 13, 2015, 6:13:56 AM4/13/15
to europass...@googlegroups.com
Hi,

I'm printing Curriculums in three languages Spanish, Portuguese and English.
Without setting the printting preferences the date format of English is different from Portuguese and Spanish.

In English the date is in the following format :
WORK EXPERIENCE
Jan 2013–Jan 2015
EDUCATION TRAINING
2012–2013

In Portuguese and Spanish the date appears in this format:
WORK EXPERIENCE
jan 13–jan 15
EDUCATION TRAINING
13–15


I would like that both Portuguese and Spanish languages appeared like the English format. 
But I can't find information about the format I should apply.
Can you help me?

The other issue found is that the printing preferences to Work and education list  period are only applied to the first element of the list, the other elements get the default setting.
I attached the XML and Word with printing preferences set (001 and 002) and without printing preferences set 003 and 004. 


Many Thanks,
Admilson
001XML.xml
002XML.xml
001Word.doc
002Word.doc

admilso...@gmail.com

unread,
Apr 13, 2015, 6:15:56 AM4/13/15
to europass...@googlegroups.com
Word and XML without printing preferences
003XML.xml
004XML.xml
003Word.doc
004Word.doc

Europass Interoperability

unread,
Apr 14, 2015, 11:29:46 AM4/14/15
to europass...@googlegroups.com
Dear Admilson,

You can use one of the following date formats in an Europass CV XML:
  1. text/short
  2. text/long
  3. numeric/short
  4. numeric/medium
  5. numeric/long
If you don't specify any date format in the XML, the text/short one (#1 above) applies by default.

However, the text/short format has a slightly different representation in the generated document (doc, pdf, odt), depending on the language of the document. So, if you use text/short in an English document, the date will appear as "14 Apr 2015". If you use the same format in a Spanish document the date will appear as "14 abr. 15", if you use it in a Portuguese document it will appear as "14 ab 15" and so on.

So, to answer your first question, if the desired format is text/shortit is not possible to make the dates in the Portuguese and Spanish versions of your document appear like the ones in the English document. Nevertheless, you could use a format other than text/short such as numeric/long ("14/04/2015") which you already use in your XMLs or even text/long ("14 April 2015") where the year always displays with 4 digits, regardless of the language. 

Concerning your second issue, this is because you only override the default date format in the first item of your Work Experience and Education lists. Let's take "001XML.xml" for example, where there are two <WorkExperience> entries and two <Education> entries as well as the following printing preferences:

<Field name="LearnerInfo.WorkExperience[0].Period" show="false" format="numeric/long"/>
<Field name="LearnerInfo.Education[0].Period" show="false" format="numeric/long"/>

The "WorkExperience[0]" and "Education[0]" parts above refer to the first item in the list of work experiences and to the first item in the list of the education entries respectively (imagine that it's an array/list with zero-based indexing). So, you set to numeric/long the date format for the first work experience and the first education entry, but since you don't touch any other items in the lists, the default format applies, which as explained above is text/short

In order to use the same format in all of your list items, you have to repeat the same printing preference for each one of the list items. So, if you have two work experiences and two education entries, the printing preferences should look something like this:

<Field name="LearnerInfo.WorkExperience[0].Period" show="false" format="numeric/long"/>
<Field name="LearnerInfo.WorkExperience[1].Period" show="false" format="numeric/long"/>
<Field name="LearnerInfo.Education[0].Period" show="false" format="numeric/long"/>
<Field name="LearnerInfo.Education[1].Period" show="false" format="numeric/long"/>

As you can understand, [0] refers to the first item in the list, [1] to the second item in the list, etc. Please also check the attached 001XML-FIXED.xml and 001XML-FIXED.doc for the end result.

As a sidenote, it is strongly suggested to validate your XML instances against the Europass XML Schema because currently I can see a lot of problems with them (missing elements that are required, etc.). The REST API doesn't currently complain and accepts your XML, but this might change in the future.

Please let us know if you need anything else.

Best regards,

Dimitris Zavaliadis
Team Europass
001XML-FIXED.xml
001XML-FIXED.doc

admilso...@gmail.com

unread,
Apr 20, 2015, 6:46:25 AM4/20/15
to europass...@googlegroups.com
Dear Dimitris,

Sorry for taking so long to answer, I was in holidays. Thank you for the Quality response, it solved my issues :)
Regarding the XML construction I've tested what works and what doesn't so that I could optimize the work.
In nationalities for instance I realized that its only needed to send the Country Code, the label is not mandatory.
Which makes some sense and this is more comfortable because the code(e.g EN) doesn't depend on the printing language. For the programmer it means that he does not need to have a copy of the same country for each language that its application supports(e.g. es - Inglés; pt - Inglês; en - English ).
Is correct to assume that the label will continue to be not mandatory?

In the languages I put the right country code, but I put the label I want to print.
I also send the ProficiencyLevel with blank values, due to a requirement. 
And lastly I doesn't send the DocumentInfo as it doesn't had impact in the test's I made.

Is it possible to indicate which of this points are critical to update?

Thanks for the attention,
Admilson

Europass Interoperability

unread,
Apr 21, 2015, 5:49:59 AM4/21/15
to europass...@googlegroups.com
Hi Admilson,

This is an all-or-nothing approach, it doesn't really make sense to fix only half of the issues, your XML instances should be 100% valid. Even if we never implement strict validation in Europass, there might be 3rd party applications out there which will reject your documents if they're not 100% valid.

Now, about your specific remarks:

In <code> / <label> pairs (nationalities, countries, languages, etc.) you can simply set the <code> element with the correct value and the REST API will find the suitable <label> for you, according to the language of the document. This is perfectly valid according to the Europass XSD and I think it's safe to assume that it's not going to change. 

Please note that it's also possible to include only the <label> element, in case you cannot find a suitable code (you already do this in Work experiences with <Label>Arvorado</Label> for example).

Concerning languages, you can remove the entire <ProficiencyElement> (including children) if you don't want to set the proficiency level at all (e.g. <ForeignLanguage><Description><code>en</code></Description></ForeignLanguage>). It's also possible to leave out specific categories such as <Writing> for example.

Finally, <DocumentInfo> is necessary not only because otherwise the document doesn't validate against the Europass schema, but also because it contains some very useful information (e.g. the type of the document and the version of the Schema the document adheres to).

I also took the liberty to validate 002XML.xml and explain below the specific points that you need to address in order to make it valid. The corrected document is attached here for your reference (002XML-FIXED.xml).
  1. Lines 3-9: added <DocumentInfo>
  2. Lines 53-56
    1. Before
      <MetadataList>
      <Metadata key="dimension" value="591x608">Value</Metadata>
      <Metadata key="number-of-pages" value="1">Value</Metadata>
      </MetadataList>
    2. After
      <MetadataList>
      <Metadata key="dimension" value="591x608"/>
      <Metadata key="number-of-pages" value="1"/>
      </MetadataList>
  3. Line 120 (in the original document): removed <Activities></Activities>. If it's present, it has to have contents, it can't be empty.
  4. Lines 138-141
    1. Before
      <Description>
      <Code>PT</Code>
      <Label>Japonês / Japanese</Label>
      </Description>
    2. After
      <Description>
      <Code>pt</Code>

      </Description>

      The language codes should always be in lower-case.

      You can also change it to the following if you want to keep the same label (I'm pretty sure "pt" doesn't correspond to Japanese :-)):
      <Description>
      <Label>Japonês / Japanese</Label>
      </Description>

  5. Lines 151-153
    1. Before
      <Description>
      <Code></Code>
      <Label>Estoniano / Estonian</Label>
      </Description>
    2. After
      <Description>
      <Label>Estoniano / Estonian</Label>
      </Description>

      If <code> is present, it has to have contents, it can't be empty.
  6. Lines 169-171 (in the original document): removed the following
    <Driving>
    <Description />
    </Driving>

    If it's present, it has to have contents (e.g. <Driving><Description><Licence>B</Licence></Description></Driving>), it can't be empty.
That's it for now, let me know if you need anything else.

Regards,
Dimitris Zavaliadis
Team Europass
002XML-FIXED.xml

Europass Interoperability

unread,
Apr 21, 2015, 6:05:22 AM4/21/15
to europass...@googlegroups.com
Also, forgot to mention that your XML files fail to be uploaded to the Europass online editor (despite that they work with the REST API).

This is because their encoding is set to "UTF-8 with Signature". If you change it to plain "UTF-8" they can also be uploaded to the online editor.

Regards,
Dimitris

admilso...@gmail.com

unread,
Apr 28, 2015, 8:11:59 AM4/28/15
to europass...@googlegroups.com
Hi Dimitris,

Thank you for your extra work indicating the precise things that I need to alter and the detail regarding the UTF-8 with Signature!
I understand and will correct this things :)

Best Regards,
Admilson
Reply all
Reply to author
Forward
0 new messages