Hi Tim, an important issue for me too! The archetypes I am working with (Endoscopy ones) are already quite big and there are 11 (yes eleven) languages! I completely translated one of them (MST Colon) and it is 6359 lines long. I also had quite an experience with localisation of software in past where strategies similar to gettext was quite practical and successful.
BUT: I think all aspects of the "knowledge" - including the translations should better stay within the Archetypes. Because: 1) If the purpose if for 'resuse', then having multiple files around can be quite problematic. 2) same with specialisations - have to maintain a complex versioning process 3) For non-English primary language archetypes, this will make it impossible for others (well 99% of the rest of the World I guess) to understand without using tools (i.e. a text editor). However, with the current scheme we must also decide how to modify translations. I don't know if this has been discussed before but translation changes are frequently needed and as I can see this does not necessitate specialisation. Perhaps with versioning of archetypes - but then this might create many versions out there and can make things complicated. In this case your proposal seems more appropriate. One straightforward solution might be to adopt a propriety file type for representing archetypes - i.e. a multipart file. Still human readable but can accomodate more than a single file and perhaps support other file types as well....However I fear this is how usually things get very complicated and result in the increase of the ciriticism that openEHR is too complex and technical! So as result, I am inclined towards keeping it all in archetypes - unless we find a sound and sensible approach ;) -koray -- Koray Atalag, MD, Ph.D Clinton Bedogni Research Fellow The University of Auckland, Department of Computer Science, Private Bag 92019, Auckland 1142, New Zealand Tel: +64 (9) 373 7599 ext. 87199 Fax: +64 (9) 308 2377 Email: koray at cs.auckland.ac.nz Tim Cook wrote: > Hi All, > > I raised the below CR and I wanted to open up discussion on this issue. > Actually I brought it up a few years ago but I don't have a record of > where/when; now. > > I know that this have a major impact on implementers but I think the > current way we handle translations in ADL is a monster that is only > going to get worse. > > Thoughts? > > --Tim > > > -------- Forwarded Message -------- > From: Tim Cook (JIRA) <jira-admin at openehr.org> > To: timothywayne.cook at gmail.com > Subject: [JIRA] Created: (SPEC-302) Translations embedded in the ADL are > not efficient and should instead use 'gettext' catalogs. > Date: Tue, 28 Apr 2009 21:47:02 +0100 (BST) > > Translations embedded in the ADL are not efficient and should instead use > 'gettext' catalogs. > ---------------------------------------------------------------------------------------------- > > Key: SPEC-302 > URL: http://www.openehr.org/issues/browse/SPEC-302 > Project: Specification > Issue Type: Change Request > Reporter: Tim Cook > > > Archetypes like openEHR-EHR-OBSERVATION.blood_pressure.v1 with four > translations are huge and tedious to process the languages. > openEHR should adopt the standard use internationalization (i18n) and > localization (i10n) tools that use gettext catalogs. This is the industry > standard approach to performing translations. Tools like POEdit are open > source and cross platform http://www.poedit.net/ > > More info about gettext is here: > http://www.gnu.org/software/gettext/manual/gettext.html though it is about > the GNU set of tools there are others. > > What will openEHR-EHR-OBSERVATION.blood_pressure.v1 look like with 10, 15, > 100 translations? > > > > ------------------------------------------------------------------------ > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090429/149464e7/attachment.html>
