Moodle in English: Translators heads up: proposals to change the Moodle translation process

Translators heads up: proposals to change the Moodle translation process

by koen roggemans - ଶୁକ୍ରବାର, 13 ମାର୍ଚ୍ଚ 2009, 5:09 PM

With the upcoming 2.0-version, it seems to be a good idea to rethink the translation process. One problem is the amount of unused strings/helpfiles in the language packs: they remain there for backwards compatibility, but are a pain for new languages to start of, because it is impossible to know if a string/helpfile is still used or not.
So we should do a clean-up and come up with a good system to avoid this in the future.

Some work and thinking has been done in bug MDL-15252, but this has to be discussed in this forum and decisions have to be made eventually.

To summarise:

1) clean-up of unused string/help files

2) branching the rest of languages

1 requires 2 i.e. we cannot perform the clean-up properly without branching, but branching language packs has it risks too:

1) translators must LEARN to use and commit them properly

2) translation interface must support branches

3) lang download (both from web page and from within moodle must know about branches)

Branching involves having a Moodle 1.9, a Moodle 2.0, Moodle 2.1 and perform each translation in the corresponding one and committing the translation to the corresponding branch.

We could make a clean start for Moodle 2.0 on a new download page, like we did for 1.6, but then the problem starts building up if we don't do branching.

Another track is to install on a Moodle.org box all maintained Moodle versions, give translators an admin account on it with the translating capability set. A demo course can be stored (and may be restored every X time) to have something to play with. The box updates daily
A robot can daily move the translated files in the correct CVS branch.

This solves
-no need to do anything with CVS for translators - branching is automatically
-no need to install anything for translators: translating is done on the Moodle servers
-no need to change anything on the translation interface

This is problematic AFAIK for
-moodle.com: yet another set of installations to maintain
-translators who like playing with CVS

-translators who like translating directly on the files.
Maybe those last two groups can have a CVS account to do their thing on the files, but I would keep that as an exception.

Sorry for this long post - with this length it hardly looks like a summary

Please give your ideas and comments!

Average of ratings:Useful (5)

Re: Translators heads up: proposals to change the Moodle translation process

by David Mudrák - ଶୁକ୍ରବାର, 13 ମାର୍ଚ୍ଚ 2009, 8:05 PM

Hello world, some quick notes to this... (copy goes to the tracker as well)

Helen has mentioned some issues with the help files for the new gradebook. The current correct way is to introduce new helpfiles (eg. foobar2.html instead of current foobar.html) instead of changing the current ones so the backward compatibility is preserved. But we know this leads to a lot of obsoleted strings and helpfiles... bez života

I would really love to see language packages being branched souhlasit

. I think we will have to help our translators to use CVS branching features. More documentation, step-by-step tutorials etc. is needed but after several successful commits this might become an easy daily task. How many translators use CVS at the moment?

Eloy noted that the translation tool itself should support branches. How? The translation is done against the English pack at a given branch. How would we get English files from several branches into a single installation?

Ad collaborative translation: to be honest, I am very sceptical here. IMHO every language pack needs a maintainer (Pythonists use term BDFL) who makes decisions. Code maintaining is about communication, not permission. I am little bit afraid of terminology wars, mentioned by Koen.

Let me be brave and propose using GIT instead of CVS for language packs překvapení

(what??? is David crazy???). Not only branching and merging is much easier in GIT than in CVS. But it also fits our needs and process much better. Try to imagine:

every language pack is maintained by a single "official" translator. They keep branches for all stable releases.
anybody can decide to create their own fork (clone) of the official language pack repository and start making modifications, changes etc.
the maintainer can decide to pull changes from other repositories, compare them against their own etc.
language ZIP packs are generated auto-magically from all repositories available.
every site administrator may choose which version (clone) they want to use.

Average of ratings:Useful (1)

Re: Translators heads up: proposals to change the Moodle translation process

by Ralf Hilgenstock - ଶୁକ୍ରବାର, 13 ମାର୍ଚ୍ଚ 2009, 11:09 PM

Hi David,

just a short report about collaborative translation process for the german version.

We've a separate instance with the actual developer version. Its updated all two to three weeks. en_utf8 language is updated every week.

A group of 2-6 people is working on the translation. Coordination is done in a course.
From time to time we update into CVS.

The same instance is the home for the German docs.moodle.org/de team. So its easy to coordinate both translations. If the docs team finds a bad translation they can discuss it with the German lang team or change it at once.

Suggestions from the community are discussed at the moodle.org German Community in a forum.

We have experience with this way of collaboration in the third year and its working fine.

Average of ratings:Useful (3)

Re: Translators heads up: proposals to change the Moodle translation process

by David Mudrák - ଶନିବାର, 14 ମାର୍ଚ୍ଚ 2009, 12:24 AM

Hi Ralf,

thanks for your comments. Of course the small-team approach may work with Moodle translation. We have very similar process and frequency set up here in Czech.
What I was talking about and what I am afraid of are frequently asked questions on how to set up Moodle so it allows wider community (eg. whole class of student, whole school etc.) to commit new strings. My not so clearly expressed point should have been that contributions are warmly welcome but only several users (two, three) should have CVS access. These CVS maintainers must review contributed translation to keep the pack internally consistent.

--mudrd8mz

Average of ratings: -

Re: Translators heads up: proposals to change the Moodle translation process

by Nicolas Martignoni - ଶନିବାର, 14 ମାର୍ଚ୍ଚ 2009, 1:47 AM

Hi David,

I think the point is not to give access to more people for committing translations, neither to change the way teams of actual translators cooperate now. It's about offering (better) tools enhancing collaboration in translations.

I too woudn't like at all that anybody changes this or that in the translation, for evident quality reasons. I strongly believe that a leader (benevolent dictator ) is needed for coordinating a good translation work. (And like you I'm convinced that CVS access should be restricted to this benevolent dictator.)

Koen's proposition of setting a special Moodle instance for helping translation work is in this sense a very good one. Remains the following problem: how will the translation "leader" of each language have the possibility to manage who can modify the strings, and which ones?

Thanks for your ideas,

Nicolas

Average of ratings:Useful (1)

Re: Translators heads up: proposals to change the Moodle translation process

by Ralf Hilgenstock - ଶନିବାର, 14 ମାର୍ଚ୍ଚ 2009, 3:05 AM

I red and understood the idea of branches for translations and this is a good idea.

A whole school submitting new translations is a interesting idea but we have engouh instruments to do this in courses. Its not a good idea to do this directly in the local language version of the school. Often user have ideas to cahnge something and dodn't know that strings often are used in different contexts. A good exmaple is the 'description' string in activities. Mostly it is used as 'introduction', in assignments it is a 'task'. If we use in different cultures different wordings for such things we can't translate it in different ways. May be some people in a translation group have the overview and can see the consequences. For local translations its not a problem to define a separate role with limited access to te language system. I don't think we have to discuss local school wide translations or any projects supporting translation process.

Branching is a much more relevant aspect.

Direct translation in files creates a lot of problems with deleted signs -;- or -'-. And its confusing in large files like moodle.php or admin.php.

Average of ratings: -

Collaborative Translation

by Leonardo Lazarte - ରବିବାର, 30 ଅଗଷ୍ଟ 2009, 1:58 PM

The way to organize collaborative translation might depend on different cultures, resources and individuals involved. Even if the Benevolent Dictator model is working, what happens when they retire, disappear or lose interest in the project? piscando

When Moodle was still at version 1.5 we used a hack to complement the official Brazilian Portuguese translation. It worked quite well, and it received valuable contributions from dozens of persons.

Main features:

It used a hacked version of Moodle 1.5;
The front page showed percentage of untranslated strings in each php file;
The front page showed untranslated help files;
Anybody could register and make contributions, either modifying existing translations or adding new ones;
Translated strings and help files showed different status: green (translated and approved), yellow (translated but not reviewed) or red (not translated);
We used a course forum to discuss which terms to adopt and other issues;
Moodle's translation interface was modified to show: original English string, "reference language" string, space to translate to "present language"*;
The most accurate or active contributors were granted "Editor" status, so they could "approve" or "approve with ammendments" the contributions;
Each translation received a "grade", which contributed to choose Editors;
The language pack was automatically generated daily (when version 1.6 came out, we generated the UTF8 version as well). Both files were avaliable for public download;
Changes in the official version (reference language), as well as changes in the English version were highlighted for reviewers to take action.

*(Usually the "reference language" was the official Brazilian Portuguese translation and the "present language" was the Brazilian Portuguese translation under construction, but the translator could chose other settings to help in understanding the meaning of a string in a given context. For example, "reference language" could be Portugal's Portuguese or any version of Spanish)

Any other ideas to build a similar, updated, "Community Translation" setup?

This setup could be useful in building language variants, for example things are called different in a university context than in a basic school.

Regarding old strings, I agree with Petr's proposal, they should remain available, and the idea of a database seems quite good.

Average of ratings: -

Re: Translators heads up: proposals to change the Moodle translation process

by Milan Jaroš - ଶନିବାର, 14 ମାର୍ଚ୍ଚ 2009, 1:40 AM

May the Force be with you.

Average of ratings: -

Re: Translators heads up: proposals to change the Moodle translation process

by Karoly Fabricz - ସୋମବାର, 16 ମାର୍ଚ୍ଚ 2009, 5:15 PM

- As regards branching:
What exactly is 'branching'? Subversions of a language pack (possibly tuned to specific users) or subversions of Moodle?

- As regards the translation process:
Translation is extremely individual. The critical issue is that of maintaining consistency. Moodle changes, and changes rapidly. The terms used in Moodle, however, do not change considerably from one version to the other. Even if they do, that is basically addition of new terms, rather than re-formulation of content. Therefore, the translation process is suitably managed by one person or a team of translators working in closest cooperation. That person (or team) should have the final word and be responsible not only for consistency in the use of terms but also appropriateness of style. Management of localization based on strings produced by others is a formidable task. If it is appropriate to presume that localizing Moodle into a new language includes at least 6 man-months hard work, then coordinating such localization contributed by 2, 3, or more translators would increase the process several times (comparison, checking against source, adjusting to existing chunks of translation, etc.)
As the main tool for maintaining consistency is the translation memory and such a tool is not available for localizing Moodle, the only feature a translator might welcome as assisting her or him would be some editable and automated term lookup utility. A utility I am dreaming about would display translations of a term along with related contexts. This way, a translator would find the appropriate term for grade vs. score vs. point, or answer vs. response vs. reply, to mention just two cases.
Such a tool might also offer a way out of the real catch: that of the strings being written according to English grammar.

As regards obsolete strings:
- Those keeping an eye on the development process will know how version tracking is done in Moodle. If that involves logging string changes as well, then language packs could be adjusted to version changes of Moodle. There may be a utility which detects the strings that are never applied in a version. I would be surprised if it were the case that unused functions are retained in the 'distributions' over several versions. In the ideal case, such versions would be generated, along with their corresponding language packs, by the developers.

Some further suggestions:
- For localizers, it would be very helpful if developers tried to write strings consistently, avoiding any display features (n number of spaces to indent content, line breaks, etc.), rush wording, and so on.
- When perceived by the developer, a note for translators would be very helpful in ambiguous situations (e.g.: $string['yes'] = 'Yes'; - this may imply agreement, existence, an option, approval, and so on, each time possible requiring a different solution in the target language). I remember string like 'From' and 'To', where, without context, one cannot decide whether that is mail details, calendar details, or a range.
- On introducing new features (and, hence, new terms), a hint on their meaning would save us from having to dig the web and spend a lot of time finding out about the term concerned.

Sorry for being too long.

Karoly

Average of ratings:Useful (3)

Re: Translators heads up: proposals to change the Moodle translation process

by David Mudrák - ସୋମବାର, 16 ମାର୍ଚ୍ଚ 2009, 6:29 PM

> What exactly is 'branching'?
Basically branching is keeping different versions of the same code in the one place (repository). Moodle code is branched - we have branch HEAD (the most recent development version, ie the future 2.0 at the moment), branch MOODLE_19_STABLE (current 1.9.x code), MOODLE_18_STABLE (current 1.8.x code) etc.
While all the Moodle code including the English strings are branched, language packs use the only branch (HEAD) common for versions.

Average of ratings: -

Re: Translators heads up: proposals to change the Moodle translation process

by Karoly Fabricz - ସୋମବାର, 16 ମାର୍ଚ୍ଚ 2009, 7:22 PM

So branching is versioning. Would it be impossible to try and produce language packs in line with the versions? Is lack of such interconnection due to the fact that a number of language packs are incomplete? And is it because Moodle evolves at a rate which language packs can only follow with a lag?

Average of ratings: -

Re: Translators heads up: proposals to change the Moodle translation process

by David Mudrák - ବୁଧବାର, 18 ମାର୍ଚ୍ଚ 2009, 12:32 AM

The correct future procedure will probably be to have separate installation for every Moodle version you want to translate. So if you want to maintain the translation of stable Moodle 2.0 and development 2.1-dev, you will have two different versions installed from branches MOODLE_20_STABLE and HEAD. And you will have two language directory folders.
The cons for translators are that either 1) you have to learn how to merge a newly translated string from stable to head or 2) you will have to put the translation into both places manually. In any case, you will commits changes into cvs twice.
Thats actually how developers work with bug fixes right now. You commit the fix into the stable and then merge it into the head (or they fix it in head and backport it to the stable version).

Average of ratings: -

Re: Translators heads up: proposals to change the Moodle translation process

by Tim Hunt - ବୁଧବାର, 18 ମାର୍ଚ୍ଚ 2009, 11:02 AM

Of course, it would be conceivable to make the translation tool multi-version aware - more work, of course, but it could be worth developing it.

What I mean is, when you are editing the string in Moodle 2.0, it would display a message next to each string like

"The string is also in Moodle 1.9 and 1.8, with the same translation."

"This string is new in Moodle 2.0"

"This string is also in Moodle 1.9, but translated differently as '.....'."

Average of ratings: -

Re: Translators heads up: proposals to change the Moodle translation process

by Karoly Fabricz - ବୁଧବାର, 18 ମାର୍ଚ୍ଚ 2009, 3:54 PM

Tim,

That functionality should be inherent in the system, and would be a good basis for translators to produce version-specific packs.

Average of ratings: -

Re: Translators heads up: proposals to change the Moodle translation process

by Petr Skoda - ମଙ୍ଗଳବାର, 19 ମଇ 2009, 4:35 PM

Hi, I did not read everything above, I have some previous experience with translation and maintenance of our code and lang packs though

Here is my proposal:

store every lang string in one central database with as much info as possible
keep the old rule that no string meaning may change
en_utf8 lang in main cvs is the master - it already has branches
generate/commit lang cvs files directly from main database - do not allow translators to commit any more
translators upload standard modified lang files - server sorts out the branches automatically (it learns everything from en packs)

Benefits:

100% backwards compatibility
translation process does not need to change at all - file upload instead of commit only
branching is transparent - we need to maintain it in en_utf8 pack
this would allow us to cleanup HEAD/lang/en_utf8/*
it allows completely new translation UIs and processes

Drawbacks and problems:

somebody has to implement it

Implementation:

Moodle module on moodle.org, but you already guessed that, right?

Ideas? Do you like this idea?

Average of ratings:Useful (4)

Re: Translators heads up: proposals to change the Moodle translation process

by Martin Dougiamas - ମଙ୍ଗଳବାର, 19 ମଇ 2009, 4:53 PM

+10 from me!

The upload process can be built into the local translation tool to make it even easier.

Average of ratings: -

Re: Translators heads up: proposals to change the Moodle translation process

by Andrea Bicciolo - ମଙ୍ଗଳବାର, 19 ମଇ 2009, 6:08 PM

Would be probably useful to let translators upload string/help files as well as translate directly on line.

While the upload is surely more useful when reviewing or translating large portions of language pack, translating online would speed up the process when a single new string pops up or when minor correction to existing files are needed.

The current Moodle translation tool does not allow for fine-grained main language pack translation permission, so probably another tool/change to the curernt would be needed?

Average of ratings: -

Re: Translators heads up: proposals to change the Moodle translation process

by Eloy Lafuente (stronk7) - ବୁଧବାର, 20 ମଇ 2009, 1:50 AM

Andrea, if I'm not wrong... Petr's idea is about to continue being able to translate files in your own site (no matter if you do that from the embedded editor or manual text edition).

The key is that, at any moment, you will be able to upload, say, the it_utf8/moodle.php file (from within your Moodle), no matter if it's the 1.9 the 2.0 or the 2.1 file... and moodle.org will know, automatically, where each string has to go (based in the manually maintained en_utf8 pack, that is already branched, so we know where - to which branches - each string belongs to).

Just in case it clarifies anything, ciao

PS: My only concern is about what will happen under some "concurrence" situations, like having one translations.moodle.org host available with different Moodle versions running and, at the same time, translators doing in-house translations. That will need to be clarified/sorted in case we are going to offer that service (that was one of the original suggestions from Koen, afaik).

Average of ratings: -

Re: Translators heads up: proposals to change the Moodle translation process

by Andrea Bicciolo - ବୁଧବାର, 20 ମଇ 2009, 5:21 PM

Thanks Eloy, I was missing the direct upload from within local Moodle to the CVS. This is a turnkey solution then. approve

Average of ratings: -

Re: proposals to change the Moodle translation process - update

by Helen Foster - ସୋମବାର, 22 ଜୁନ 2009, 10:42 PM

We had a brief discussion about proposals to change the Moodle translation process in our developer chat today, and I've subsequently copied Petr's translation process proposal into the documentation wiki as a start for the spec - Development:Translation 2.0.

Everyone, please feel free to edit the page, or the corresponding talk page, or comment further in this discussion.

Average of ratings: -

Re: proposals to change the Moodle translation process - update

by Andrea Bicciolo - ବୁଧବାର, 24 ଜୁନ 2009, 12:04 AM

Sad I missed the discussion. Anyway, branching is definitely needed: my +1 for the Petr's proposal.

Average of ratings: -

Re: Translators heads up: proposals to change the Moodle translation process

by Martín Langhoff - ମଙ୍ଗଳବାର, 19 ମଇ 2009, 6:04 PM

I think there are Pootle setups that allow you to operate roughly in the way you describe. Translators can work on the Pootle web UI or on upload POT files, and don't deal with the version control system. Scripts commit / merge (perhaps with human review).

I am really keen on shifting from the current model where everything is local, to a webbased model, to take advantage of the good visualisation facilities that Pootle and similar tools offer. You can see at a glance what the coverage of a translation is -- it goes from green to yellow to red as it gets more outdated.

Pootle includes a pot2php translator

If we couple Pootle (or something similar) with a bit of static analysis of Moodle code, you can also provide easy-to-access reports on unused strings and missing strings.

I don't mean we should get rid of our current moodle-based translation webapp. It can still be used to maintain local langpacks and by translators that prefer to work locally and then upload their files.

Average of ratings: -

Re: Translators heads up: proposals to change the Moodle translation process

by Nadav Kavalerchik - ବୁଧବାର, 24 ଜୁନ 2009, 3:35 AM

i am looking for a new feature to:
search a sub-string in all the strings of the specific language
and return a list (form) that i can edit them directly and save each one in its respective file.

since i (almost daily) find local translated strings that i wish to re-translate or refine.
while i am using the system BUT i am unable to remember/find them and their proper module's strings file by just guessing from the current gui page.

currently, i use the file system's file manager to search inside all the files. for the string i am looking for. but i do not always have that luxury

maybe this request should go into the tracker too ?

thanks

Average of ratings: -

Re: Translators heads up: proposals to change the Moodle translation process

by David Mudrák - ମଙ୍ଗଳବାର, 24 ନଭେମ୍ବର 2009, 6:47 AM

Hi all,

I am re-opening this thread as I would like to compile your ideas/inputs into a comprehensive specification before our big developer meeting in December.
Beside the issues that were already mentioned (branching, submitting process, external tools), the very important grammar issue emerged. That is how we are going to deal with plural forms, morphology and others.
Please see the page http://docs.moodle.org/en/Development:Languages where the final proposal and specification is slowly getting the shape.

Average of ratings: -

Re: Translators heads up: proposals to change the Moodle translation process

by Andrea Bicciolo - ବୁଧବାର, 25 ନଭେମ୍ବର 2009, 6:19 PM

Hi David,
thank you for reopening the thread, sorting up things in translation is a real need. Currently I'm a little confused about bracnhing: I see 1.9.x strings different from 2.0, but AFAIK I do not have any way to branch the translation.

Would be possible to create a stable branching before any step forward?

Average of ratings: -

Re: Translators heads up: proposals to change the Moodle translation process

by David Mudrák - ଶୁକ୍ରବାର, 27 ନଭେମ୍ବର 2009, 4:57 AM

Hi Andrea,

yes, the branching is crucial. There is an issue, though. Branching management, comparing differences and merging changes is not trivial and not all translators would be happy if they had to do it. So what we are discussing at the moment is how to facilitate these processes.

Average of ratings: -

Re: Translators heads up: proposals to change the Moodle translation process

by David Mudrák - ଶନିବାର, 20 ଫେବୃଆରୀ 2010, 3:16 AM

Hi all,

let me just inform you I am currently working massively on this. The whole thing evolved into a huge project that introduces a lot of changes in the translation process and strings handling. The specification is getting shape at Development:Languages and Development:Languages/AMOS.

Shortly (read the doc page and the mind map referenced there for more details):

At the moment, you still should not work on Moodle 2.0 translation yet, sorry
When Moodle 2.0 beta is released (March 2010 according to the current Roadmap), there will be a central portal prepared (probably http://lang.moodle.org) where thi initial translation will be done. This central portal is part of new AMOS system to store and organise the translation.
AMOS will take care of proper version tracking, managing Moodle versions etc. No longer you will have to translate strings that are not used in Moodle any more. You will have a control over what you translate for Moodle 1.9 or 2.0. You do not need to know anything about CVS to work with AMOS.
In AMOS, you can easily find not only the list of missing strings but also the list of outdated strings - i.e. strings that you had translated but they changed in English. We plan to incorporate other features into AMOS like searching for all strings that contain some text (eg "course").
During Moodle 2.0 beta testing, we will finish a tool to allow you translating at your own servers and test installations. This tool will be part of Moodle and will replace current admin/lang.php. This new tool will be also used by administrators who want to customize their translations.

Some incoming changes that you as translators should be aware of:

Help files will be replaced with ordinary strings and will be significantly shortened. For more elaboration, wiki docs should be used. Note the help system in Moodle was designed in times when there were no docs.moodle.org and we realized that most of the information from the current help files should be in wiki instead. If there is no wiki for your language established yet, you should consider asking for it. File a request in our tracker for it.
Some languages files will be moved into their plugins space. So for example current /lang/en_utf8/data.php (strings for the Database activity module) will be moved into /mod/data/lang/en/data.php. This is common location of strings in contributed plugins and becomes standard in Moodle.
We will do many moves between components, renaming string identifiers and cleaning up English pack before Moodle 2.0 beta release. Thanks to using the new Moodle strings manipulation library and the AMOS tool, this should not affect you. The system will be able to do all the operations in all language packs automatically. So for example if we move some strings from enrol.php into enrol_manual.php, this change will be done automatically in all language packs. With the current system, such a change was not possible and translators had to translate the string again.

I believe the new system will save us all many hours of work on localizing Moodle. Should you have any question regarding the linked specification documents, do not hesitate to reply this post.

Edited by David on Monday 22/02/2010: fixed misspelled 'it est'. Thanks to the colleague of mine who kindly corrected my poor Latin knowledge

Average of ratings:Useful (4)

Re: Translators heads up: proposals to change the Moodle translation process

by Ralf Hilgenstock - ଶନିବାର, 20 ଫେବୃଆରୀ 2010, 4:54 AM

Hi David,

great concept. But there is one point I disagree: shorter help information . We have lots of Moodle systems without internet access in corporate environments. In large organizations its up to now not the standard that all users get internet access. I.e. we have a huge university hospital where only 5% of the employees get internet access. They can use Moodle in the intranet.

If we cut the help files now its very complicate to give sensefull information in 4-5 sentences. Its much more work for authors to describe help informations very short if you can only use a few sentences where you need an example.

Actually we have a lot of such help files. They often describe in one or two sentences what a term is, but not how to work with it. If you are a specialist you don't need this information. You knew it before or thought it. If you didn't know what a term means it often isn't helpfull to find only a very short information.

Ralf

Average of ratings:Useful (3)

Re: Translators heads up: proposals to change the Moodle translation process

by David Mudrák - ସୋମବାର, 22 ଫେବୃଆରୀ 2010, 8:26 PM

Hi Ralf,

the point is not to get rid of built-in help but to make it more valuable actually. The usability of built-in help in Moodle improved in 2.0. Help can be now displayed as a contextual hint or description of the field without any clicking the icon and opening the help in a new window. Help is displayed in a bubble just by moving the mouse cursor over the help icon. It is common in other web based applications. Look at how help is sorted out in Mahara, for example.

From my point of view, contextual help should be just a description of what the given form element or control widget means or does. It is not a place where users should learn about the underlying concepts (like roles or capabilities).

Also note, if we are not able to describe what the user is expected to do with the given page element in several sentences, there is apparently some usability problem. And dozens of lines in help is not the right solution of it.

In case of institutions with their own Moodle server without Internet connectivity, there is a way of setting up a local mirror of Moodle docs site. Moodle has a support for linking against local documentation mirror and I am sure syncing the online version of MediaWiki to the offline standalone version is possible. They won't be able to survive disconnected forever, anyway. The future is in the cloud processing and using the potential of the networked world, not fully supporting disconnected islands...

Average of ratings: -

Re: Translators heads up: proposals to change the Moodle translation process

by Ralf Hilgenstock - ସୋମବାର, 22 ଫେବୃଆରୀ 2010, 10:38 PM

I understand the problem. But its not practicable to set up a mirror of Moodle docs. We are running in lots of problems in corporate environments. In some parts of Germany we have Moodle systems at schools as inhouse systems because the internet conncections are not strong enough. They don't have internet connections.

Cloud processing is one idea of organizing servers and services. But its critisised very often also. We shouldn't think in one direction only.

Some years ago we discussed engaged SOA concepts as the future. Today its only one concept. There are lots of others.

Average of ratings: -

Re: Translators heads up: proposals to change the Moodle translation process

by David Mudrák - ଗୁରୁବାର, 25 ଫେବୃଆରୀ 2010, 8:38 PM

I did not know it ever existed but there are offline Moodle Docs packages to be downloaded from http://wimski.org/docs/

Thanks Eloy for providing the link.

Average of ratings: -

Re: Translators heads up: proposals to change the Moodle translation process

by Andrea Bicciolo - ସୋମବାର, 22 ଫେବୃଆରୀ 2010, 10:48 PM

David,

although there is sure a way to mirror MediWiki locally, it is needed to setup and maintain an external system (MediaWiki) just to read the documentation. To me, and I guess for many users, it looks like a complication of things that could be (and basically are) really simple.

Average of ratings: -

Re: Translators heads up: proposals to change the Moodle translation process

by koen roggemans - ସୋମବାର, 22 ଫେବୃଆରୀ 2010, 11:50 PM

hm, yes. It is yet another webapp to maintain...
It's my weekly Thursday morning job (unless something urgent is notified earlier) to check and if necessary update all webapps on our servers ...

Average of ratings: -

Re: Translators heads up: proposals to change the Moodle translation process

by Andrea Bicciolo - ମଙ୍ଗଳବାର, 23 ଫେବୃଆରୀ 2010, 4:52 PM

Hi Koen,

not sure if I correctly understand: are you saying using a third party app to read Moodle docs is something we can't avoid when Internet access is not available? mixed

Average of ratings: -

Re: Translators heads up: proposals to change the Moodle translation process

by koen roggemans - ମଙ୍ଗଳବାର, 23 ଫେବୃଆରୀ 2010, 6:43 PM

Hi Andrea,

In the scenario where most of the help moves to Moodle Docs, you would have to install a Mediawiki with a backup of Moodle Docs restored on it on your LAN to be able to access the help in Moodle Docs without an internet connection.

Average of ratings: -

Re: Translators heads up: proposals to change the Moodle translation process

by Nicolas Martignoni - ଶନିବାର, 20 ଫେବୃଆରୀ 2010, 4:54 AM

Hi David,

Thanks for these infos. I can't wait your AMOS. Some questions though:

How do you intend to allow "power translators" that, like me, have an "internal" workflow, to import/export translations made in an external tool (editor, POedit, etc.)?
Do you intend to support very special chars in AMOS (for french, the non-breaking space is mainly of concern)?

Cheers!

Average of ratings:Useful (2)

Re: Translators heads up: proposals to change the Moodle translation process

by David Mudrák - ସୋମବାର, 22 ଫେବୃଆରୀ 2010, 8:36 PM

Thanks for the points Nicolas.

Once we will know the demanded formats, we will be able to write export/import features into AMOS. So you will just visit the AMOS page and export the current English and French snapshot into some XML file suitable for your tool. Then you will upload the translations done in your environment back to AMOS and it will incorporate it into its database. Technically, the web interface at AMOS page will be just one of possible sources of translations but the underlying structures will be able to process other sources as well.

Special chars like the French quotes, non-breaking spaces or Czech accents must be supported, of course. UTF-8 itself should be the only limitation.

Average of ratings:Useful (1)

Re: Translators heads up: proposals to change the Moodle translation process

by Nicolas Martignoni - ସୋମବାର, 22 ଫେବୃଆରୀ 2010, 11:16 PM

Hi David,

Thanks for the clarification about import/export feature.

Regarding the non-breaking spaces char, my concern is that those are sometimes gobbled by the web browser (i.e. transformed in normal spaces without further notice). So we should be very careful that AMOS implementation doesn't allow gobbling of any chars by the web browser.

Good luck on the implemetation

Average of ratings: -

Re: Translators heads up: proposals to change the Moodle translation process

by David Mudrák - ମଙ୍ଗଳବାର, 23 ଫେବୃଆରୀ 2010, 12:26 AM

AMOS implementation doesn't allow gobbling

I am not sure I can promise that (or actually I am sure I can't). The AMOS translation UI (which is just one part of the whole AMOS system) is just a web application and at the end, just an HTML form with a submit button. If your browser silently removes nbsp's and replaces them with plain space chars (as you well tested in MDL-6688), how is server supposed to know that?

What I can promise is that once nbsp arrives to the AMOS server, it will not throw it away. If it would, that would be an obvious bug.

Average of ratings: -

Re: Translators heads up: proposals to change the Moodle translation process

by Nicolas Martignoni - ଗୁରୁବାର, 25 ଫେବୃଆରୀ 2010, 4:23 AM

I'm well aware that this is a browser bug question. I'm just fearing that if such bugs still occurs in modern and widespread browsers, risk exists that the adoption of AMOS GUI won't be optimal.

Let's try and see.

Cheers !

Average of ratings: -

Re: Translators heads up: proposals to change the Moodle translation process

by David Mudrák - ଗୁରୁବାର, 25 ଫେବୃଆରୀ 2010, 8:34 PM

Nicolas, what tool and format would be optimal for you? Are you using some plain text editor or some sort of translation tool?

Average of ratings: -

Re: Translators heads up: proposals to change the Moodle translation process

by Nicolas Martignoni - ଶୁକ୍ରବାର, 26 ଫେବୃଆରୀ 2010, 2:57 AM

Hi David,

Yes I'm using a simple but powerful editor (BBEdit on Mac OS X), integrated with CVS. But I don't argue that every translator should work like me

I'm convinced that AMOS is the way to go to clean the mess of the lang packs and to permit different lang packs for different Moodle versions.

But as a "power translator", I would like to have the same facility to use an external editor (useful eg. for grepping an changing a term when necessary) and import/export the modified files. I don't care about the format. The current one or any XML would do it. For the sake of the standardisation, gettext format have to be considered too.

PS. I read the backlog of the lang2.0 dev meeting (sorry I couldn't be there). If you're interested about the way I'm getting the context for translating strings, here it is: I'm following acurately the development of the new features (thanks to the CVS commits mailing list), and when some string is added in the english lang pack, I get the context from a test dev site, translate it and commit it as soon as possible (I've freezed all this since Martin asked us to do so for 2.0 strings).

Average of ratings: -

Re: Translators heads up: proposals to change the Moodle translation process

by Mitsuhiro Yoshida - ଶନିବାର, 20 ଫେବୃଆରୀ 2010, 12:58 PM

Hi David,

It's a very nice transition.

I have two questions.

Are we notified when new strins are added?
Are we notified when core strings are changed?

Mits

Average of ratings:Useful (1)

Re: Translators heads up: proposals to change the Moodle translation process

by Tim Hunt - ସୋମବାର, 22 ଫେବୃଆରୀ 2010, 5:58 AM

Well, the basic idea is to store all the history of all the strings in a big database.

Once that foundation is in place, it is quite easy to write a script that detects things like new or changed strings, so there are all sorts of possibilities for continually enhancing the translation tools to match the ways that translators like to work.

Basically, if that sort of thing is not in the first version of the tool that David writes, it will be possible to add it later. However, David has to get the first version of the tool working in time for Moodle 2.0 beta, so don't expect all the bells and whistles in the first version.

Average of ratings:Useful (2)

Re: Translators heads up: proposals to change the Moodle translation process

by Mark Stevens - ଶନିବାର, 20 ଫେବୃଆରୀ 2010, 4:32 PM

David,

Great work as always. Two thoughts to share:
1. I'd like to 2nd Ralf's concern to shorten local help files. Relying on Internet help will cut off many Moodle users from help.
2. Is there any way to plug into Google's translation API? Let Google take a whack at it and then Lang Pack moderators clean up/approve?

M

Average of ratings: -

Re: Translators heads up: proposals to change the Moodle translation process

by David Mudrák - ସୋମବାର, 22 ଫେବୃଆରୀ 2010, 8:38 PM

Mark,

see and vote for MDL-21670 (Automatic translation for Moodle UI strings with Google Translation API)

Average of ratings:Useful (1)

Re: Translators heads up: proposals to change the Moodle translation process

by Ralf Hilgenstock - ରବିବାର, 21 ଫେବୃଆରୀ 2010, 10:10 PM

Hi David,

what happens with Third-Party-Modules and the translation of this tools?

ralf

Average of ratings:Useful (1)

Re: Translators heads up: proposals to change the Moodle translation process

by David Mudrák - ସୋମବାର, 22 ଫେବୃଆରୀ 2010, 8:48 PM

Good point.

There are basically two scenarios. The 3rd party modules committed into our CVS contrib area can be tracked by AMOS automatically as if they were standard plugins. The current development leads to a consistency in strings storage and there should be no differences between standard plugins and add-ons.

Alternatively, the plugin author (or actually whoever with the required permission) can take the file with the English strings definition in the plugin and upload it to AMOS manually. The file is parsed as if it comes from CVS checkout and the strings are registered in the AMOS database. They can be translated then as other strings. The pack containing the translation of the module can be then downloaded from AMOS as any other component, in the format suitable for deploying at Moodle server.

Average of ratings: -

Re: Translators heads up: proposals to change the Moodle translation process

by Andrea Bicciolo - ସୋମବାର, 22 ଫେବୃଆରୀ 2010, 4:56 PM

Hello David,

thank you for the excellent news about the upcoming translation process. I see many improvements in the translation work flow on your proposal and AMOS looks a great tool.
However, to get a meaningful translation, it is crucial to know the scope of the strings, since different scope (or context) may need different wording: according to the wiki docs page, that appears to be an open point.

About the hlep files, I'm siding Ralf and others about the need of keeping them together with the language pack since many setup are inside intranet environment with limieted or no access to the Internet.

Cheers,
Andrea

Average of ratings: -

Re: Translators heads up: proposals to change the Moodle translation process

by koen roggemans - ସୋମବାର, 22 ଫେବୃଆରୀ 2010, 5:53 PM

It seems like everybody is happy with the proposed change, except some reservations about the disappearing help files.

Open for debate of course: the help files as they are now (separate html-like files in a folder structure) are technically a bit of a pain to fit the new structure. It is a lot easier to handle the help the same as the strings. We have seen an evolution in that direction already in admin.php, where most of the help is not in separate files.
Also for translators it is a lot easier to translate something like
forumsubscribe
forumsubscribe_hlp
because you have string and helpfile together: using the same wording becomes easy without searching.
So generally I think moving away from html files and put everything in the string files is a good idea (I don't know about performance, since the growing string files have to go in server memory during processing of the page).

The readability of some long help files in a pop-up screen is not good. A lot of help files contain too much information and that is the main reason of moving a lot of information to the docs and keep the help files short.

So I see two options to satisfy the needs of the off line Moodle installations and the on line installations:

go ahead with shortening the help files and create a downloadable Moodle docs backup so an off line Moodle docs can be made available.
Leave the content of the long help files as they are and add a summary above all the long help files for those who don't want to read the whole thing.

Average of ratings:Useful (2)

Re: Translators heads up: proposals to change the Moodle translation process

by Andrea Bicciolo - ସୋମବାର, 22 ଫେବୃଆରୀ 2010, 7:02 PM

Koen,

apart from performance ponit of view, can't see problems in having help files in lang strings rather than in html files. If help files in lang strings better fits the new structure, I think moving html to strings is ok.

In my opinion there are still some open points:

contrib modules
easy way to find scope of strings: translating without knowing scope or context of strings yields poor translations

About help files, my +1 goes for keeping help files in lang packs, as the are strictly bound to the context where they appear: think to contextual help files of activity module settings, it is really simple clicking on the help icon an get the setting options explained. Up to now in docs.moodle.org to get direct detailed help of a specific setting you need to browse the whole documentation pages and find the setting you are interested in.

Docs.moodle.org and language help files could be a two tier documentation system: help files (for sure shortened in many cases) could provide immediate contextual help while docs.moodle.org could provides a manual-like documentation with a higher and more general point of view, usage scenarios and so on.

Another thing to be considered is how to keep track of changes in docs.moodle.org: as far as I can understand, AMOS currently addresses language strings only.

Average of ratings: -

Re: Translators heads up: proposals to change the Moodle translation process

by David Mudrák - ସୋମବାର, 22 ଫେବୃଆରୀ 2010, 8:56 PM

Hi Andrea,

yes, the in-place translation is a known request. Currently I propose the following way. Every user with the capability to do local translations can enable a special mode of running Moodle for himself/herself. In this mode, the list of all strings that were used at the given page is displayed in the footer. Actually not only the list but the whole form to translate them. So whenever these users spot some wrong translation or missing string, they just scroll down the page and fix it.
Local translations can be then uploaded into AMOS. Ideally everybody can upload their suggestions and the lang pack maintainer just cherry-picks or approves them into the official branch.

The thing we must discuss carefully yet is the format in which the strings are sent from your sites into AMOS. We need to keep some meta-information (like who is the author of the proposal, against which revisions of strings the customization was done etc.) so I incline to use some sort of XML format for this.

Average of ratings:Useful (1)

Re: Translators heads up: proposals to change the Moodle translation process

by Andrea Bicciolo - ମଙ୍ଗଳବାର, 23 ଫେବୃଆରୀ 2010, 4:44 PM

Hi David,

yes I read your contra-proposal in docs, however there are no tracker issue. Your idea is dropped or still alive?

Average of ratings: -

Re: Translators heads up: proposals to change the Moodle translation process

by Andrei Băutu - ରବିବାର, 21 ମାର୍ଚ୍ଚ 2010, 6:51 AM

I have done something similar recently. See http://abautu.blogspot.com/2010/03/click-to-translate-feature-for-moodle.html

Average of ratings: -

Re: Translators heads up: proposals to change the Moodle translation process

by Andrei Băutu - ରବିବାର, 21 ମାର୍ଚ୍ଚ 2010, 3:15 PM

I submitted a patch against 1.9.7 here: http://tracker.moodle.org/browse/MDL-21880

Average of ratings: -

Re: Translators heads up: proposals to change the Moodle translation process

by Ralf Hilgenstock - ସୋମବାର, 22 ଫେବୃଆରୀ 2010, 10:23 PM

Hi Koen

translating strings and help information at the same place is good. I personally can't discuss the technical aspect about formats.

The main problem with help files are today not the ten long help files. The problem are help files that doesn't explain anything. Often they are to short. They only tell what obvious.

Some long examples: A very good and often used example is the help file for bulk import of users. This is a long one. But if gives the information you need to do the job in the moment. An other good example but not well formated is the information about wiki types and groups. The table contains all information you need for understanding.

An interesting but not really good example is the help file for cloze quiz questions. Its long, it shows an example, but it didn't explain the structure of coding clozes.

My interest is that users find with one click the relevant information. I'm in fear that a concentration on documentation wiki brings us in a situation that we will discuss in three years to delete the help files and only to use the wiki. On the other side developers will not write help files and we have help files that say only: 'You'll find more information in the documentation wiki at this page.'

ralf

Average of ratings:Useful (2)

Re: Translators heads up: proposals to change the Moodle translation process

by koen roggemans - ସୋମବାର, 22 ଫେବୃଆରୀ 2010, 11:45 PM

Ralph, I think the help files you mention are the ones that should indeed not be shortened. I use them myself each time I do a bulk upload, group wiki, cloze question.

David is right about the interface being self explanatory, but some things are just too complicated. But some help files are really too long and not useful at all: try the help button next to message or format when typing a forum message to name two.

It becomes very clear that rewriting/shortening the help files should be done very carefully, keeping all arguments in mind.

Average of ratings: -

Re: Translators heads up: proposals to change the Moodle translation process

by David Mudrák - ସୋମବାର, 22 ଫେବୃଆରୀ 2010, 11:59 PM

I like the example of users bulk import. I use that help often, too. But let me say the only information I am repeatedly looking at is the list of valid field names that must and that can be provided in the CSV file. That is something that would fit into the help. We can elaborate on how to prepare this CSV in details in the docs for those who are importing for the first time.

Also, the future content of the help and whether to shorten it or not does not block the technical solution. Even if help will be the same as it is now, it can be stored as an ordinary string, no need for a separate HTML file.

Average of ratings: -

Re: Translators heads up: proposals to change the Moodle translation process

by Ralf Hilgenstock - ମଙ୍ଗଳବାର, 23 ଫେବୃଆରୀ 2010, 6:50 AM

A help file should be helpful for you and me as advanced users. And we understand a very short information.

But a help file should be much more be written for the standard user or a beginner. And this is a great problem to keep short but to be helpfull for this type of users.

Average of ratings: -

Re: Translators heads up: proposals to change the Moodle translation process

by David Mudrák - ମଙ୍ଗଳବାର, 23 ଫେବୃଆରୀ 2010, 12:10 AM

This is a list of issues that you can vote for or where to provide your objections. I have already put URL of this thread into the last one.

MDL-21690 Central master database of all strings and their translations
MDL-21635 Decide how to implement information in langconfig.php in AMOS
MDL-21693 Drop _utf8 suffix from language codes and folder names
MDL-21694 Move language files to the plugin space
MDL-21695 Replace built-in HTML help files with proper strings

Average of ratings:Useful (2)