Rockstor locale

Features
1

To @suman and all community members:

What do you think about creating localizations for Rockstor &&/|| Rockstor docs?? I thought about this talking with suman about a pull request (warning for shadow copies, adding a non panicing alert linked to Rockstor docs). Thinking about translations for at least french, german, spanish

I can care about eng to ita translation

Flyer

2 Likes
2

Just linking to a forum thread that has some history and ideas on approaching translation already:

And the issue on the same support translations

3

You’ll get major points for taking up this task! I can help but can’t own or prioritize this work at the moment. I see that Phil listed a couple of pointers with more information. I think this may take a good amount of effort and would indeed be cool to achieve.

4

Ok, first finish tasks with anacron like and then start thinking about this

@phillxnet do you wanna “play” with me on this?? As @suman says it will be a huge task :slight_smile:

1 Like
5

@Flyer Like @suman I’ve rather got my work cut out at the moment and need to prioritize those things that I’ve already committed to I’m afraid. I think translation / accessibility is a major feature for sure but given that in the WebUI it will require every user facing string to be abstracted by the chosen mechanism that’s going to be a big task. I put in a suggestion or two in the other thread as a way of trying to contribute what I could, but bar android development where there’s a ready made system in place from the start I’ve just had no other experience with it.

I see the main initial difficulty being the choice of system, ie string/doc abstraction, which obviously has to be accessible both to the technologies Rockstor uses, ie in the WebUI and in docs (.rst) and the commit / dev systems in place ie github and jenkins in order that changes be integrated / tracked and testable. That system also has to be accessible to non technical translators ie a web page anyone can go to that states the changes made since the last translation in a particular language and the % coverage to date in each language. This all must ideally be in an opensource offering as well given our continued attempts to stay as much on the open side as is possible.

So big job but I see the first step as choosing the best technology that conforms to our needs and open goals.

Of course as you know doubt appreciate that job is only going to get bigger as our docs and features grow so hence I would agree that this would be a great thing to get started on but just don’t think I can put any more time into it myself for a bit. Sorry. I do keep trying to nudge the docs along but we also have our work cut out there given Rockstor’s fairly rapid development.

Oh and I’m shamefully monolingual (in English as it goes :grin:).

However once we have settled on an acceptable choice of system that will never turn around in the future to bite us (ie must be opensource in my opinion and hosted by the Rockstor infrastructure) then there is always a bunch of google translate cut and paste to get the bulk of our stuff moved over so at least then translators can tidy up what’s there already.

From a quick look via wc -w find . -name '*.rst' it seems we are now > 35,000 words in docs alone.

So to summarize I completely agree that this has to be done at some point but I’m also concerned that we pick the right system for us up front first as otherwise we risk wasting many peoples time and effort.

6

@suman and @phillxnet
Hi guys, maybe I’ve got an idea :bulb: (not for docs, but at least for rockstor core)

While thinking about Phillip talk about the great matter of choosing right way to accomplish Rockstor internationalisation, on my work i was also dealing with a huge & boring task for backup (remote external system shutdown on 6 april and i knew it only 2 days ago xD) forcing me to collect data via curls on 4-5 xml/html files of 15MB each, so i solved it with lot of bash coding and XPath!

Then, while looking my black screen logging, i thought: ok, why not to use Xpath client side on Rockstor?!?

Going to explain:

  1. if we want a system enabling users to contribute with translations data on DB is not the right way, the only solution is a “gittable” structured file (xml file or a json file)
  2. what do we need working on an xml/json file? an “inline editor” from Rockstor for data entry (maybe or maybe not) and some .py to insert data, and on client side, to render text??

First solution: server side checks and xml/json reading (i don’t like this)
Second solution: it’s all on client side, json/xml structure is only for non english language, cos’ english words act like an index + dom structure (Ex. a div with id=mytext on Xpath is //div[@id=mytext], its inner text is referenced by text() so we can write xml/json index referencing all Rockstor dom “containers” and contents)

Will reference this with an example ASAP

Flyer/Mirko

1 Like