OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-l10n message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [ubl-l10n] [IDD] Cost Centre (cbc:AccountingCost)

Ok Jon,
then I will send the whole revised IDD to the list before monday.

As requested by JPLSC I applied the fixies on top of their latest revision.

The same is for ESLSC because I was unable to contact Oriol and I think
spanish version has not been revised yet.

So now the IDD will contain both yellow and green highlighted definitions
to indicate revisions.  In my understanding LSCs will have to restore the
original background when the localization work will be complete.
We have to note that the original background is not always "empty" (as
white) but could be "light green" depending of the information item type.
So I think I can easely restore original background colors automatically
for all templates.

About ITLSC I'll provide the 1.2 revision before the end of the next week.

About DKLSC as I remember we have to wait their final localization and
apply fixies to their templates.


> Roberto Cisternino wrote:
>> Hello Jon,
>> it seems the UBL 2.0 Errata 01 is not including the Cost Centre
>> definition
>> change (see cbc:AccountingCost) for all invoice types.
>> The 6.15 fix (about cbc:AccountingCost) should be applied to all
>> invoicing
>> documents: self-invoices, credit note, ... so on.
>> I would suggest to update the IDD now, even if the Model is not updated
>> yet.
> I'm sorry, but we can't do that.  The IDD consists of translations
> of an approved OASIS Standard (UBL 2.0 as corrected in Errata 01).
> Those translations have to reflect the text of the Standard, even
> if it is wrong.
> As I said in a TC call a few months ago: this is not the last
> error you will find in UBL, even in the corrected version. Nothing
> as big as UBL will ever be completely free from errors; it just
> doesn't happen. We will be releasing another version long before
> that point is reached.  So the goal is not to release a completely
> error-free set of translations; the goal is to release a set of
> translations that conform as closely as possible to the original.
> This may seem like a strange position to take when the error is
> right in front of us, but that's how it works in localization. If
> you start to make changes to the localized versions independent of
> the original, you run into problems similar to what happens if you
> start forking a code base -- you get versioning chaos.  Better to
> note the correction and work it into the next revision (2.1).
> There is a scheduling aspect to this, too: as long as we keep
> making changes to the translations, we cannot release them into
> the public review process.  We are almost a year behind in
> releasing the IDD due to the Update; we can't keep doing this.
> Of course, there is nothing to prevent the LSCs from noting the
> error in text that accompanies the translation.  They could even
> put it right into the cell containing the definition, something
> like "[This definition is in error and is expected to be corrected
> in UBL 2.1. It should read xxxxx...]."  But this is a decision to
> be made by the individual LSCs.
> Jon

* UBL Italian Localization SubCommittee (ITLSC), co-Chair
* UBL Online Community editorial board member (ubl.xml.org)
* Italian UBL Advisor
* OASIS NEWS italian translator

  Roberto Cisternino

  mobile: +39 328 2148123
  skype:  roberto.cisternino.ubl-itlsc

[UBL Technical Committee]

[UBL Italian Localization Subcommittee]

[Iniziativa UBL Italia]

[UBL Support]          (prevista migrazione su ubl.xml.org)

[UBL Online Community] (...in avviamento)

[Gruppo Esperti UBL]   (...in avviamento)

[Free UBL Writer @ JAVEST]

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]