Help files are in help/ folder of graphene-ui repo. They are static files so no need to fetch them on the fly.
We are using markdown (.md files) so it's very easy to edit them - you don't even need to know html. Also github shows .md files prerendered - this makes it very easy to browse and edit them. Here is an example https://github.com/cryptonomex/graphene-ui/blob/master/help/en/index.md
I'm very doubtful that external translation tool like Transifex would be helpful here - it just adds complexity..
As I see it, once the complex part is ready, the benefits of having all the essential content focused on a single platform that is designed for collaborative continuous internationalization can be huge. A worker proposal could fund Language Coordinators for the most relevant languages and the value added to the network could be very significant. Ecosystem and it's contents will be constantly growing and changing.
It's already implemented for bitshares.org and docs.bitshares.eu. Also for non github users it's being pretty easy and motivating to translate graphene-ui on transifex. We already have Turkish, Italian and Spanish volunteers working on it pretty fast, with no need to compare or merge locale files to match keys or having to learn github at all. When locale-en.js is committed, changes are pulled from raw github, applied on transifex and translators notified. If a finished translation is not on github or it's incomplete there, I'll manually make a push request.
I like the approach of taking graphene-ui help content directly from github markdown pages.
In that case, it wouldn't be problematic to automate pushes from pages translated and reviewed, nor pulling pages from github when they change, as there's no code interaction beyond links. We have a set of rules to define if and how strings can be translated.
It's not so complex either:
http://docs.transifex.com/integrations/github/If you agree I can implement that integration on a fork so you can decide if it is worth. My goal is not to interfere in the development process at all. On the contrary i'd like to achieve an integration that let devs released from localization process, and at the same time making this process simpler and unified at one place.