we are trying to work out the best approach to translations of the openEHR website. The mechanism for the website itself is probably straightforward:
for each language xx, we create a copy of the current website under a directory /xx/, and push this to the Github repo that contains the website
or perhaps separate repos, one per language?- the people who want to do the translation work clone the repo, replace the EN text with their language and upload the changes
we push the changes to the main website
Most URLs in the website are relative, so this should work. Clearly changes on the main website need to be reflected over time on the other websites, but we can rely on proper commit comments in the Git repo to take care of that.
First question - does this seem a reasonable workflow to adopt?
The second question that I can see is: what is the starting URL & location? Taking Japan as an example:
Shinji’s group already has openEHR.jp. Currently it is their own website. However, with a translated form of the international website, would it make sense for openEHR.jp to point to www.openEHR.org/jp? If so, then the translated international website would need a prominent link back to the current openEHR.jp. OR… if they prefer to land on the current openEHR.jp, what URL should get a user to www.openEHR.org/jp - presumably just that.
These questions apply to all languages, but not all locations or languages equate to a country. For example, if we made www.openEHR.org/es, I am sure we only want one of those, even though there can technically be some small differences between the Spain / Central & South America variants. But there is no openEHR.es and openEHR.org.es (which appears to be taken) would correspond to Spain only.
In the end, I think the best we may be able to do is to provide a www.openEHR.org/xx for each language translation, and it will be up to local openEHR.orgs to add links or Apache rewrite rules to connect to these locations. So multiple Spanish-speaking countries could all point to this ES translation of the central site.
Subject:
Re: translating the openEHR website - Also a localised content?
From:
"Gunnar Klein, NTNU" <gunnar.klein@ntnu.no>
Date:
17/12/2012 16:47
To:
<openehr-technical@lists.openehr.org>
Dear Tom and other techies,
A wonderful idea with translated content and the general work flow described sounds feasible to me. However, I think it would make sense not to require the various non English language sites to follow exactly the master openEHR. Firstly, because it would make sense to launch some content in several languages before everything is translated, and in several cases I think all the content will never be translated, some of the technical stuff will be better read in original English in some countries. However, the "LOCALISED" openEHR web pages may also contain material that relates to national work, in particular of course as directly related to openEHR implementations. Documents may be uploaded in various languages with content that it will not always make sense to translate.
Regarding the excellent Japanese initiative, I suggest they should be offered to move the content to the main site but with the openEHR.jp as a pointing entry. Such sites may be establsiehed in other countries also but I think they shall generally not have there own content but be pointers to the openEHR.org. Especially where the same language is used in several countries and continents it may be a complicated proliferation which in one sense is welcome. An offer to one person or a small group of 2-3 persons per geographical area to work directly with the openEHR international site makes sense to maintain some control over content of the foundation content.
If needed, I can start to work now and then on a Dutch translation. In my profession it is sometimes good to think about something else, sometimes, and translation-work is one of the right things to do. I would do it in my own tempo.
In my case, I would follow exactly the master OpenEHR, I wouldn't want to take responsibility for changes on my own behalf.
OK, that is my offer, I guess I will be noticed if I can add some useful contributions.
Just for fun or the same reason, I wrote a page in Wikipedia in Dutch about OpenEHR, now exactly a year ago.
Main reason, however, was not fun, but to get some Dutch marketing done, without Wikipedia-page something is not really important in the Netherlands.
I had quite some problems getting it accepted, the jury thought it was too technical, it took a lot of arguing.
Once someone rejects a page, others don't bother to interfere, because they respect each other decisions without wanting to know details.
Anyway, I got it through, after quite some flattering.
I also wrote one about archetypes, but that was rejected by the same person, and I never succeeded to return it.
And making too much noise could cause this OpenEHR page to be rejected again.
Having translated portal would appeal wider range, especially for beginners.
On the other hand, openEHR.jp site has another accountability as the domestic
artefacts repository. We can have two sites for their responsibility.
The workflow on GitHub seems reasonable for me, but we need to try it to prove that it works.
Your suggested URL openehr.org/jp is good for us, Japanese community, but I think redirection openehr.org/jp to openehr.jp is not useful as described before. Localisation has two dimension just
you mentioned, language and geographical location. I do not have good idea for Spanish community,
but I think it is a common problem for international language community, even in English.
There are many English speaking countries, but localisation is necessary, just now Koray is trying.
@Shinji: Ok so let’s assume we set up each language on the central site as openehr.org/jp etc, and you will be able to use where you like at your end. @Gunnar: I take your points, but not sure what to do about them - i.e. I am not sure what to practically do about the need for a mix of local and central content, other than for local websites / wikis etc to be created as we are doing. I think the main thing we can do now is to keep the central site small, which was a conscious objective from the start. The local needs in different countries will clearly be different, so I think we just have to see how the local web presence in each place develops. @Bert: thanks for the offer. All - we are still working on some content, so the central website is not ‘finished’ .. but it will never be, there will always be something more to do. So we could start as an experiment just one translation job to see how the workflow works. The main thing we would need to agree on is probably how we document the changes we make on the central site in Git, so that translators can detect what changes have happened that they need to reflect. I think we might be ready to try this experiment in the next week or so (we are still adjusting some mechanical aspects of the site). It sounds like we make the experiment either Japanese or Dutch - who wants to be the guinea pig? (I.e. who has time - thomas
I forked GitHub web-site project. Can I make /jp sub-directory to work
under top?
Could you please point it out where should be?
Japanese translation would appeal capability of translation much, I will try it.
About openEHR.org.es, lets say it’s more like a group of interest than an oficial branch of the openEHR.org site translated to spanish.
That’s what we have right now, but in the future we can find a way to have specific contents generated by us and oficial openEHR contents translated to spanish (and meet the requirements (?) to be an official openEHR community based on a common language instead of a country/region).
BTW, openEHR.org.es is for spanish speakers, not a Spain based community.
I’ll try to motivate my colleagues to help translate the openEHR.org contents to spanish, and maybe form a small group of translators.
Are we really talking about fundamentally different websites or just translations?
In other words, are we just talking about changing the "labels" according to openehr.org/[language-code] or could it be that a few of the pages of the "/es" (for example) website would have different content (perhaps adapted to local conditions)?.
If the websites are addressing a [language-users] community (as it was mentioned before) and not a specific geographic area, maybe it would be worth taking the time to add (or borrow) some minimal internationalization features on the current website.
Therefore, instead of translating all resources, we just translate a big key/value dictionary (in text format).
What do you think?
All the best
Athanasios Anastasiou
P.S. The site already uses php anyway, so why not make it a bit more "active"?
Shinji, it might be a bit early to do too much work on it, but why not get the workflow right. In Git, you should see the following structure: We will create a ‘lang’ directory at the top level. . Don’t worry about the ‘lang’ appearing in URLs, we can deal with that in the Apache rewrite rules. I think if you just try to translate some of the content on the home page, and some of the stable-looking pages one level down - don’t go too much further because there are still major changes going on in some directories. I’ll get Adriana to create a list of what appears to be stable and what is not. If you do a bit of work, and push it back to your fork, we’ll then get it pushed into the main repo (I still have to work out exactly how we do this in Github ;-). We’ll then upload it, create an Apache rewrite rule that does: /lang/([a-za-z])/(.*) → /$1/$2 which will have the effect of making the physical directory be served as , which I think is a bit more normal. Let’s just try this in Japanese, then I suggest the next step is for us to provide a list of paths we think are stable enough to translate - then some other languages can get started. - thomas
Shinji can be the first one to take the pain, hopefully we'll have it worked out for you in a week's time. Ok, more than a week's time. Some warm wine drinking may slow things down...
I understand the idea, but what would openEHR Spain do if it wants its own Spanish local website, to do with Spanish locations, legislation, companies etc? It would mean that openEHR.org.es was taken. I don’t see any problem right now, but it might be worth just thinking about how domains will be organised in the future… - thomas
[Gunnar - your posts are bouncing - think your subscription is under an old .se address - do you want to check? (see how easy it is to find everything now ;-)]
Subject: Re: translating the openEHR website [From Gunnar Klein] |
Here I am talking about a translation of (parts of) the central website (as Gunnar said, some bits probably should just stay in English). We expect there to be separate websites in specific locales, either on a country basis, or like Pablo said, openEHR.org.es that covers a Spanish language community. Those sites are managed by people in those locales, and reflect local interests & needs. Koray has been working on some general concepts to get ‘order’ in this world. Eventually I would suggest that we think about adopting similar colours / scheme from the central website, to make all these sites look ‘openEHR-ish’. For website developers of any local sites, please feel free to copy anything you see in the . Well there is technically no reason not to do that - since if we put each translation under its own directory, other content can go into those directories. But I do think we should not try to make the central site do everything - there is a lot of local content for each country that would be very local indeed. Note - we can however keep adding more rules to Apache to do redirections so that local content has nicer URLs. I could be proven wrong however! Adriana only just started looking at this, and has no special expertise in this area. There doesn’t seem to be any textbook on how to do this, and info on the web is sparse. If you know the magic process for internationalising a website, I’ll get her in touch with you and you can help her out. I don’t know how that works - since most content pages (i.e. the most useful stuff to translated) is static HTML. My approach (possibly to dumb) would have been to run the pages through google translate and then fix all the wrong bits any suggestions welcome. - thomas
Eventually I would suggest that we think about adopting similar colours
/ scheme from the central website, to make all these sites look
'openEHR-ish'. For website developers of any local sites, please feel
free to copy anything you see in the Git repo of the central site
<https://github.com/openEHR/openehr-website>\.
Yes, that was my next question (where is the main "template" and css files?) :-).
But I do think we should not try to make the central site do everything
- there is a lot of local content for each country that would be very
local indeed. Note - we can however keep adding more rules to Apache to
do redirections so that local content has nicer URLs.
I could be proven wrong however!
Alright, then we are indeed talking about localised resources which would mean that content would change.
If the websites are addressing a [language-users] community (as it was
mentioned before) and not a specific geographic area, maybe it would
be worth taking the time to add (or borrow) some minimal
internationalization features on the current website.
Adriana only just started looking at this, and has no special expertise
in this area. There doesn't seem to be any textbook on how to do this,
and info on the web is sparse. If you know the magic process for
internationalising a website, I'll get her in touch with you and you can
help her out.
Yes, no problem.
There is no "magic" solution it just involves substituting the actual message with a look-up to a table that is different for every language. Having a stable template would also help in this case.
I have created a branch in my local copy to look at just that, so i am going to put together an example in just one page and share it later.
Therefore, instead of translating all resources, we just translate a
big key/value dictionary (in text format).
What do you think?
I don't know how that works - since most content pages (i.e. the most
useful stuff to translated) is static HTML. My approach (possibly to
dumb) would have been to run the pages through google translate and then
fix all the wrong bits
Yes, that's what you can do once all the messages are pooled in one file....Google can produce "interesting" results, especially when translating specialised terminology so maybe it is quicker to go through the actual translation (for a native speaker).
Hi Thomas, we’re on early stages of community creation, diffusion of openEHR and tools building, right now collisions of domain names are not a priority. When the time arrives I think we’ll manage
- thomas