the problem is not "having it in git", the problem is to make eltrans able to manage the translations on a git format (it was designed to do it from an svn format), this requires some big rewrites on eltrans and in fact, I think many things needs to be rewrited on eltrans since its a very old tool and has very old code, and this also means:
- a lot of work
- a lot of betatests needed
- a lot of new bugs since lots of things will change
that's another issue, the accounts are "svn accesses", to be ported on git its needed to write a "git access system", which... well is much more complicated
in fact switching from svn to git is not a prior needed thing, but it can make the code more reliable, but the thing is that it is not too much important and this change requires many work
please give me some time, im trying to make some things work better on the website at the moment + building an updated iso + wanting to publish something about covid in a newsletter (yeah we are going to erradicate it before this happens, hopefully lol), + etc
I just received a github notification from @TheTechRobo for something about "a github project for debating", im not sure what it was exactly (seems expired) but for debating things about eltrans this is the best place to do it (our forum) 
mmh sounds good if the code will be "the same but better", this means things like:
- functions should be called with arguments, so variables must be passed in that way instead of using global variables, unless a global variable has its own purpose
- variables must be set as local (as much as possible) in order to make the code more reliable
- an important thing is to make the code more readable, this means using better naming convention, in short, an english sentence sorted in the inverse way just like an object parent to the object children, for example using something like "eltrans_translation_file_get" instead of "get_file_translation_eltrans" (just what wordpress and many things do in an horrible way)
- using elive-tools functions instead of own functions made (if they are available), you have them pressing el_<TAB>
well thats a long list of examples, eltrans requires a few modifications to make it compatible back and also, if possible, to improve the code to be better and more readable/reliable, but the second is less prior
If you want, try to send a small push request to see how your changes looks like
note that the "git VS svn" thingy is not about the code but about where the translations are stored, see: https://dev.elivecd.org/timeline , and https://dev.elivecd.org/changeset/4928#file11 - etc
like i said, we are not (not exactly), eltrans is on github, the svn thing is where the translations are stored, so eltrans (and all the packaging tools and related things to the translations for elive) uses svn commands to manage them (get them, upload changes, diff them, etc etc), this means a big rework on all those tools if we want to switch to git, but i still don't know if is a good idea, for example, eltrans accounts are simple web accesses and generated from a cli tool to http apache kind acceses, this is easy to create, for git, is needed an ssh key... now, eltrans was designed to be EASY for users to be able to collaborate making translations, using apache http accessess is very easy and they don't need to know anything more than its password, with the second, they needs to generate an ssh key, know wtf is that and how a terminal works, and it will be able to use only on -that- computer (unless the user knows how to use its ssh keys on other computers). Eltrans was wrote in the past because of the need to make an easy "not programmers" way to let users helping with translations
