Translation 2014 - current issues

let’s go :-) this is about translating the help pages:

- for a big and multi-lingaul translation / localization project like this i think it needs more than translators. i think there’s the need of a very well structured communication layer and versioning system beneath the surface, which e.g. makes the single translators / committees aware of changes in other translations.

- an example: the fingerprints of riseup’s ssl-keys are documented in the help system. this is imo very important and vital for a provider who states to care about online security. the fingerprints change every year with the new ssl-keys – but there’s no mechanism (and obviously no individuum, too) that reminds the translators of adapting the translations.

- it would be nice to have a database-layer beneath the help-system, to be able to insert fields that are common to all translations (e.g. the mentioned fingerprints, or adresses, links…)

- it would be nice to be able to switch between the languages inside the help system. i couldn’t get friend with the current “navigation tags” thing yet. at least i tried to. i’m not too much a friend of complex dynamic webpages… but in my ears this cries for some php(?) hacking.

- to me it appears that the whole help system would want to be carefully reflected before starting into this translation project. i’m afraid of putting lots of work, time and idealism into this and realize after half a year or so, that it’s already fully out of date / fragmented / …

- i think there are numberous open source version controlling systems out there that could be easily adapted to (our) needs. i don’t have much experience with any of those – just want to say: there’s probably no need to write one from scratch (although this might be a fascinating project ;-)

- THE MOST IMPORTANT THING WITH IT-PROJECTS IS THE DOCUMENTATION AND THE DOCUMENTATION OF THE DOCUMENTATION AND THE MAINTENANCE OF THAT!!! it happens so fast that the-one-who-knows disappears for whatever reason and the whole thing looses its contact to the ground. i guess that’s why so much of the commercial software is such a crap.

hi liloz,

- an example: the fingerprints of riseup’s ssl-keys are documented in the help system. this is imo very important and vital for a provider who states to care about online security. the fingerprints change every year with the new ssl-keys – but there’s no mechanism (and obviously no individuum, too) that reminds the translators of adapting the translations.

Yes, we do not even have a list of documents that cover those keys/certificates in any language. It would be a great work to create such an index.

- for a big and multi-lingaul translation / localization project like this i think it needs more than translators. i think there’s the need of a very well structured communication layer and versioning system beneath the surface, which e.g. makes the single translators / committees aware of changes in other translations.

update Jan/2014 It is possible to see changes on english help pages. If there are additions in other languages they should be ported back to english, then everyone can see them.

What you describe is possible with a issue tracking system (like redmine) in combination with a revision control system (like git). Every document has a ticket and commits to pages describing the change, like “#7 new ssl-certificates”. If you are watching ticket #7, a mail informs you about every change no matter which language has been updated. That indeed would be great progress.

- it would be nice to have a database-layer beneath the help-system, to be able to insert fields that are common to all translations (e.g. the mentioned fingerprints, or adresses, links…)

As a first solution we can collect the info in a wiki table with a row for comments, like in newsletter index.

The focus is on other things until everything is translated and major developments leap are done.

- it would be nice to be able to switch between the languages inside the help system. i couldn’t get friend with the current “navigation tags” thing yet. at least i tried to. i’m not too much a friend of complex dynamic webpages… but in my ears this cries for some php(?) hacking.

I agree, currently it is not possible to switch between languages in crabgrass as one only sees documents of the own language group and english.

• DONE for the newsletter I prefer intuitive naming like “newsletter-2012-01” instead of “january-2012-newsletter-for-translation”, "< index > " navigation links to the index and other languages (as common for many software manuals, like started here)
• DONE As for newsletters all translations go into one page, for the help we should decide, if it makes more sense to have separate documents for every language

- to me it appears that the whole help system would want to be carefully reflected before starting into this translation project. i’m afraid of putting lots of work, time and idealism into this and realize after half a year or so, that it’s already fully out of date / fragmented / …

Currently best practice is to copy the english table to the own language (de fr it pt) – already done for fr it pt. However they may not be merged. Still missing: es gr ru (both last are problematic because of the UTF8 problem of this crabgrass version).

- THE MOST IMPORTANT THING WITH IT-PROJECTS IS THE DOCUMENTATION AND THE DOCUMENTATION OF THE DOCUMENTATION AND THE MAINTENANCE OF THAT!!! it happens so fast that the-one-who-knows disappears for whatever reason and the whole thing looses its contact to the ground. i guess that’s why so much of the commercial software is such a crap.

FIXED The language switch for help.riseup.net at the bottom left has no effect.

Hi,

Unfortunately there is no fancy underlying keys based system to manage and track things :( Translation is sort of a hack on top of the “webpages served out of a crabgrass backend” hack.

I think karden’s idea is using a wiki to track things at first is good. Maybe a table: rows are documents, columns are language, and cells are date last reviewed? And then have a workflow/process document that explains how to update a translation?

I agree for common stuff like the certs that should be split out in a non-language specific way (I’ve been meaning to do that with the certs in particular)

I agree having clean naming and organization is needed so things don’t get too confusing.

The language switch at the bottom only does things if a page is translated, otherwise the page defaults to english. (it might be nice if it said in the right language at the top “sorry that page isn’t translated yet, here is the english version”)

please see this page for further responses we.riseup.net/riseup+translation/transl...

reposted from irc: Transifex, Pootle or Launchpad: Which one to choose?

• #riseup-translation @ irc.indymedia.org (SSL: 6697)

update Jan/2014 Reading the above a lot has progressed with translation in 2013

• the language switcher works again
• the newsletter archive has been published in multiple languages
• german navigation tags have been updated and now there is a table for german translation todos

But the problem with UTF8 persists:

chernysh: I did. But I decided not to translate the navigation tags because links with cyrillic look ugly. Like that: help.riseup.net/el/%CE%B1%CF%83%CF%86%C...