Hi Koray, I will let others respond about translations etc, but I did want to pick up on your point about multi-part file. This was an option recently consider when we were looking at a mechanism to record an MD5 Hash of the archetype. There was a desire to provide this hash external to the ADL itself whilst making it available to the archetype consumer locally so it was not necessary to query some external notary service to do the integrity check. Using a multi-part file would allow the usual PGP message and signature parts to be used. It was thought to be quite a disruptive change, but if there are other reasons to do this...
Heath From: [email protected] [mailto:openehr-technical-bounces at openehr.org] On Behalf Of Koray Atalag Sent: Wednesday, 29 April 2009 9:17 AM To: timothywayne.cook at gmail.com; For openEHR technical discussions Subject: Re: [Fwd: [JIRA] Created: (SPEC-302) Translations embedded in the ADL are not efficient and should instead use 'gettext' catalogs.] 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) <mailto:[email protected]> <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/20090430/02cce82b/attachment.html>
