May be we need to redo the trick from 1.6 over again: create a new folder in CVS: lang2, clean all packs and move them over, have a new download page for 2.x language packs

My +1 for the idea in Koen's comment.

just trying to revive this a bit... I've created the MDL-16769 subtask.

It's about to create one script to seach for unused strings across moodle/contrib given a lang pack.

David, I've initially assigned it to you. In case that isn't ok, please reassign it to me.

I think that such script can give us some interesting numbers to see, definetivelly, what to do for 2.0 (a good chance to break everything, as you know).

Ciao

From chatting with Eloy:

stronk7: well, they are two different things afaik:

1) cleanup of unused string/help files
2) branching the rest of languages

1 requires 2 i.e. we cannot perform the cleanup properly without branching, but branching langs has it risks too:

1) translators must LEARN to use and commit them properly (potential nightmare)
2) translation interface must support branches
3) lang download (both from web page and from within moodle must know about branches)

(that's the summary IMO) but, for sure, for any cleanup, we need branching

Helen: or as Koen says: Maybe we need to redo the trick from 1.6 over again: create a new folder in CVS: lang2, clean all packs and move them over, have a new download page for 2.x language packs

stronk7: yes, that's an option... but in the long term (2.3, 2.4...) we'll be in the same situation.
but perhaps "lang2" is a good moment, and we could start with it branched

stronk7: perhaps one discussion in forums could help?

asking translators and so on (they are the "key" to see if branching is going to be fairly managed by them)
they'll need to have one Moodle 1.9 another Moodle 2.0, Moodle 2.1 and perform each translation in the corresponding onw (committing to corresponding 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 exeptions

Jordan can look after the technical side of running these sites and robots etc, but people familiar with translations are going to need to lead the cleanup effort (of course this can be done from any CVS checkout).

It could enhance too the cooperation/collaboration in translation teams.

So, if we start translating collaboratively, how can we avoid conflict of translation, ideas and political stuff?
And who can manage translation groups for each language?.

At the moment, all translations that are sent to translation@moodle.org go to the language pack maintainer with CVS access. Otherwise it is send to the one that did the last send, if that is a reasonable time ago (say less then a year ago).

We'll have to come up with new strategies for language packs with occasional translation efforts ...

Yes, I have experienced some in 6 years

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...

I would really love to see language packages being branched. 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 sucessful 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 (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 automagically from all repositories available.
• every site administrator may choose which version (clone) they want to use.

Agree, correct, translation tool only will know about current installed lang files. It's the download part the one that must know about new lang18/lang19/lang20/lang21/lang directories (and the web page in downloads.moodle.org to show all them).

>Ad collaborative translation: to be honest, I am very sceptical here.

Disagree, I think that offering one Translation site for each branch is a good solution and a lot of translators can be using it online instead of local installations. Those wanting to use own servers + direct access to CVS can continue using that. Only difference is they'll need to handle branches themselves.

>Let me be brave and propose using GIT instead of CVS for language packs

• 100% disagree (for langs in particular and for moodle in general). People wanting to have clones can use git or whatever. But we need the centric approach of CVS. And merging between branches isn't really a pain if you know what is being done.

In any case, perhaps we could have one 1...10 list of tasks needed to fulfil this change? I think it's mandatory to have all the steps clearly agreed (mainly because it affects CURRENT 1.9 lang packs) before doing anything. One page in the Docs could be a good place to make this evolve IMO (apart of discussion having place here/in forums).

Ciao

as I just answered in the forum, the reason of my worries is the number of users that can actually save the strings and help files. If we open such possibility to anybody coming and saying "hey I want to make this language pack better" then editing wars may come (maybe, maybe not - wikipedia works pretty well ). If this centralized hosting is meant just as a service to the current language pack maintainers who want it, I've no problem with it.

> -100% git

ok, np. It was just a brainstorming idea. You are right: if someone wants to actually use git mirrors, they already can do so. Although I still think that switching to git would be good step for Moodle project, there is no need to start with us, poor translators :-p

> -100% git

I agree it shouldn't be introduced to translations, but this discussion did make me consider an extension to Koens idea which i'd write down - you could have moodle commit to a local git repository on the translation server (with the author credentials of the moodle user) as a way of tracking changes which happen in the translation between automated commits. If we were feeling really adventurous this could also be used as a way for any moodle user to make translations and then get reviewed for commit.