[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-dev] Codelist translations query
Then if the code definitions alone are translated it would aleviate (or remove) the need for lookups if the actual .gc files were recreated for each language - same values, translated definitions. Then I could just add the genericode (.gc) files to my translated XForms:-) Likewise it should be easier for the ERP's, etc. Cool. Thanks Steve ------------------------------------------------------------ Stephen Green Senior IT Officer Bristol City Council Room G34, Romney House Romney Avenue Bristol BS99 3HB Tel: 0117 922 3794 Fax: 0117 922 4877 Email: stephen_green@bristol.gov.uk >>> <roberto@javest.com> 24/05/07 16:26 >>> Hello Stephen, I am also very interested into code list translation. I think this should be done by translating only the definition, as codes are localized information already or international codes. We need just a way of acting I think, as code list are many. I think a code list could be translated and just located into a directory named using the locale name (the once available from the user http request on the browser) I seen some code list from NES with different languages, but I just read the specification. I think such translation could be handled by the code list standard (e.g. genericode) not UBL directly. Maybe UBL ??LSCs could provide the translation of the default genericode code lists (if not already available from the related Agency). In the time I am sure I will prepare some code list translations. Regards, Roberto Cisternino co-chair UBL ITLSC > Hi David > > Thanks. This is the sort of thing I was after. > > An example of the problem, for want of a better one, > could be my XForms which are by default standalone > but could be adapted to receive supplementary data > fed to them from a server (such as translated labels > and maybe codelist translations). > > If I were translating the labels I'd want to put them > in a separate file and reference their values from > the xforms:label elements of the XForms. I don't do > this in my own XForms since it was easier just to create > a separate form for each language (took about 3 hours > for 9 forms when armed with a draft UBL translation), > but that's not so relevant. > > With codelists there is no UBL translation of values > in the UBL IDD (International Data Dictionary - done > for UBL 1.0 and in progress for 2.0) so I haven't yet > attempted a translation. However, given time and > someone's effort (I'm told ISO and CEFACT codelists > have translations available, by the way, which I'd > have to go look for I guess), I'd not want XForms > users to have to use english code values when using > a spanish, italian or japanese XForm, say. So they'd > need to see the translated value while the english > one might have to be the one entered into the xml. > > Now I don't see much feasibility in overloading the form > with having to do lookups and having to hold all the > code values and translations so I'd expect to have to > involve some server-side stuff (which limits use of the > XForm to online use but there we go...). So there is > some scope for minimal complexity and fairly decent > performance which would be a bit of compensation if > you can't always go online - at least you'd not have > to use english even if you do have to wait for internet > connection. Ideally I'd prefer standalone but the end > user might prefer the better translation to offline > support. Well, sorry, I'm rambling. > > There's the example. Plus the xml gets sent to an ERP, > say which needs to translate the english code value into > the required language too - another scenario. > > Maybe UBL would consider what to say about using > translations of the actual code values in the actual > messages but I take it the would be expected to be english > like the markup (as if the code values were an extension > of the actual markup?). > > Maybe UBL would think about providing translations of > the actual codelists too. > > All the best > > Steve > > > ------------------------------------------------------------ > Stephen Green > > Senior IT Officer > Bristol City Council > Room G34, Romney House > Romney Avenue > Bristol BS99 3HB > Tel: 0117 922 3794 > Fax: 0117 922 4877 > Email: stephen_green@bristol.gov.uk > > > >>>> "David RR Webber (XML)" <david@drrw.info> 24/05/07 13:54 >>> > Steve, > > I'm perceiving two areas here - one is the need to provide reference > semantics of codelists - which genericode is doing. The second is runtime > use of codelists - which genericode facilitates - but then you really need > to look at the specifics of the operational use to determine the best > course. > > Obviously with a simple xslt you can generate a CAM lookup codelist from > genericode (that xslt is available for download). CAM supports up to 3 > parameters - so you can certainly cross reference between original code > values and alternate ones. The most obvious is ISO country codes in > numerics and equivalent in postal letter codes. > > Is that the kind of thing you are looking for here? I guess if you had > two genericode lists - in different languages - you could also do a lookup > into a lookup, (positionally if needed) - to obtain the equivalent > translations too. > > I'm not sure we need anything special in genericode to facilitate all this > - it appears to be doing the job it was designed for. Then implementers > need to massage that content into production configurations - and that of > course is what XML formatting is designed to facilitate in the first > instance. > > Perhaps if you had specific example to work through? > > Thanks, DW > > "The way to be is to do" - Confucius (551-472 B.C.) > > > > -------- Original Message -------- > Subject: [ubl-dev] Codelist translations query > From: "Stephen Green" <stephen.green@bristol.gov.uk> > Date: Thu, May 24, 2007 7:05 am > To: "<UBL DEV-LIST" <ubl-dev@lists.oasis-open.org> > > Greetings, > > Glad to see the codelist methodology of the TC for codelists > going to public review. The version of 'genericode' in UBL > 2.0 being an earlier version though I wondered how that > affects UBL. In particular, how best to use the latter when > there is a requirement to provide translated code values. > I guess the requirement would be to re-represent the > puiblished UBL codelist(s) in such a way that allows a look-up > where the code value meanings and/or the values themselves > have been translated. I guess you can translate the code > into CAM format too (or instead, depending on constraints > perhaps) so how to do that in a scenario of translation > between (human) languages would be valued too (David? :-) > (and for those OASIS members out there an unbiased plug > here to remember the CAM 1.1 standardisation vote by the > way). > > Any ideas? (especially from anyone on the codelists TC or > those concerned with the use of the codelist output in UBL). > > Many thanks > > All the best > > Steve > > > ------------------------------------------------------------ > Stephen Green > > Senior IT Officer > Bristol City Council > Room G34, Romney House > Romney Avenue > Bristol BS99 3HB > Tel: 0117 922 3794 > Fax: 0117 922 4877 > Email: stephen_green@bristol.gov.uk > > > > ______________________________________________________________________ > Please note the new simpler name for our website: > http://www.bristol.gov.uk > > Our email addresses have also changed - visit > http://www.bristol.gov.uk/bigchange for further details. > > Sign-up for our email bulletin giving news, have-your-say and event > information at: http://www.bristol.gov.uk/newsdirect > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org > > > ______________________________________________________________________ > Please note the new simpler name for our website: > http://www.bristol.gov.uk > > Our email addresses have also changed - visit > http://www.bristol.gov.uk/bigchange for further details. > > Sign-up for our email bulletin giving news, have-your-say and event > information at: http://www.bristol.gov.uk/newsdirect > > > > ______________________________________________________________________ > Please note the new simpler name for our website: > http://www.bristol.gov.uk > > Our email addresses have also changed - visit > http://www.bristol.gov.uk/bigchange for further details. > > Sign-up for our email bulletin giving news, have-your-say and event > information at: http://www.bristol.gov.uk/newsdirect > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org > > Roberto Cisternino --------------------------------------------------------------------- To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org ______________________________________________________________________ Please note the new simpler name for our website: http://www.bristol.gov.uk Our email addresses have also changed - visit http://www.bristol.gov.uk/bigchange for further details. Sign-up for our email bulletin giving news, have-your-say and event information at: http://www.bristol.gov.uk/newsdirect ______________________________________________________________________ Please note the new simpler name for our website: http://www.bristol.gov.uk Our email addresses have also changed - visit http://www.bristol.gov.uk/bigchange for further details. Sign-up for our email bulletin giving news, have-your-say and event information at: http://www.bristol.gov.uk/newsdirect
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]