Akademy meeting notes

[Albert Astals Cid]

Here are the notes from the Akademy meeting.

If you have something to follow up/comment i guess start new threads? Or answer this changing the subject?

Cheers,
  Albert



* Web translation solution

Unfortunately none of the strong proponents for it attended the meeting

- The direct svn/git solution will stay to make sure our current users keep happy
- We understand that using a web translation solution is potentially easier for newcomers
- Having two systems is a bit incovenient because it makes documentation harder
- It will not be possible to "commit a translation" from the web system unless you have commit access in svn

It's important that if we implement this, people that are using their own web based translation systems start using KDE's one

There's several factors that influence the tool choice: quality of translations, easiness of contribution, efficiency while translating, quantity of translations. Different systems have different strenghts/weaknesses.

We need to provide a clear path of what needs to be done in order for KDE to be able to provide a web based translation system


* l10n.kde.org

We're hoping to eventually simply kill it. It uses old PHP (the code is relatively bad). Replace it with Damned Lies from gnome (which provides some other interesting functionality like file assignments)


* Scripty improvements

Scripty code is a mix of various scripts in various languages written over more than a decade. It's not easy to maintain, we disccused several plans to improve it, both short and long term.


* Documentation

We discussed that documentation needs improvement, it's spread in several places so it's not always easy for a newcomer to know what to read.

There's differnet needs translators need to do, so it would be good if we could have different entry points in the documentaiton for each task.

The Lokalize documentation is not very good it seems (but we need to be careful, Lokalize is not used only to translate KDE so we need to make sure we don't introduce too much "how to translate KDE" references in it)


* Use of our infrastucture

We need to try to make teams use our infrastructure for things as mailing lists, team guidelines, etc. Because we are sure our infrastructure will be maintained "forever", and sometimes external ones are not so stable/maintained


* Move data files over to application repositories

We agreed that moving the data files over application repositories makes sense. This way on the svn we only have things whose translations are done via po files. Will need to contact developers to convince them it's a good thing too :)
Unrelated to that we need to improve discoverability of which applications have translatable data files.