LibreRouter: new project with software and HowTo booklets
Hi TranslateWiki team,
I wonder how to get in touch with you so that we can figure out whether LibreRouter can join TranslateWiki. I don't see any email address to write to, and the IRC webchat isn't working at the moment (and I don't usually spend any time on IRC). I will respond here to the items listed on the New Project criteria page, and hopefully this will make it clearer whether LibreRouter can join TranslateWiki.
- Openness: yes, LibreMesh software and documentation use free and open source licenses, such as GPLv3.
- Development: yes, LibreMesh is in active development, using a Git repository for version control. The project has periodic releases of LibreMesh, and will have periodic releases of other software and documentation (which has't yet reached first release). Time to get translations into use is currently unknown, and depends on how often network maintainers update the firmware on their router (perhaps we could automate part of this process to make TIU faster, or have a translation-only auto-update so as not to deal with potential software bugs and version incomatibilities between routers on a network), and how often users update Lime-App on their phones. More discussion could be helpful.
- Integration: It seems very reasonable that TranslateWiki staff could have direct push commit access.
- i18n Support: two key parts of the LibreRouter system support i18n already (LibreMesh GUI and Lime-App), though I do not know if they support the details of i18n mentioned on the TranslateWiki New Project page. I have passed the Localization for Developers link to developers and they're looking at it.
- Communication: I am the current liason, and I am not active in development. I have communication with the developers, and it's feasible that one of the developers may takeover the liason role and/or at least one developer might be active in translatewiki.net. I am a user and tester of the software and documentation.
- File formats: yes, we use translation files, I don't know if they're in one of TranslateWiki's preferred formats. Here's a translation file for Lime-App https://github.com/libremesh/lime-app/blob/master/i18n/translations/es.json , and I'll find one for LibreMesh.
We need to start translating this month, October 2017.
What else do you need to know in order to decide whether LibreRouter can join TranslateWiki?
cheers, Pato
The JSON format looks okay except we don't include the language code as a key in the file (it's already there in the filename). Would you consider changing that format?
Is the repository in GitHub your main repository?
I would request to add some message documentation to guide the translators (see https://www.mediawiki.org/wiki/Localisation#Message_documentation).
Does taking the language code as a key out of the file just mean removing the line "es": { As well as the closing bracket } ?
Yes, the repository in GitHub is our main repository.
We will add some message documentation to guide the translators based on the advice at https://www.mediawiki.org/wiki/Localisation#Message_documentation. It might take us a week or so to start adding that documentation.
I'm talking with coders... we're moving forward on changes to be more compatible with TranslateWiki, and we're coming up with questions about TranslateWiki:
1) We're looking at 4-7 different pieces of software to translate. Each piece has it's own practices of what branch development happens in, so we're getting all that info in one place. Arranging direct push commit access for TranslateWiki to the development branch of each software is part of our conversations.
2) If one or two pieces of software are ready to connect with TW.net before the others, can we go ahead and connect those? If yes, how?
3) Can the TW.net platform translate the Readme.md file for each software? Or maybe we'll have to setup a separate help folder with a file in each language, like at https://github.com/LonamiWebs/Stringlate/tree/master/help -- would that work? Is there a TW.net parser-generator for MarkDown .md files?
4) Is there a smartphone interface for TW.net, either via a web browser or a special app? (It seems that using a computer with a keyboard and at least a 10-inch screen is easier for translating, but sometimes a smartphone is the only device available to a translator.)
5) How do we include screenshots in the translator notes (the qqq messages)?
1) Are those pieces in different git repositories?
2) Yes we can. I need the basic info about the repository, push access, file format.
3) We do not have MarkDown parser at the moment. It could work as translatable page.
4) Amir is working on a Telegram app. There is also unmaintained android app. The web interface should accommodate tablets pretty well, but mobile phones are not well supported.
5) Uploading them here in translatewiki.net and using the wikitext syntax to include them. Can also put direct links to images, if they are too large, but then translators have to click.
1) Yes, each piece in a different repo.
2) The first two pieces that I think are ready:
- LibreMesh Web UI
- https://github.com/libremesh/lime-packages/tree/develop/packages/lime-webui
- format: Gettext
- branch: not yet decided. Development usually happens in a new branch for each feature or fix, and then gets merged with "develop". Here's a conversation going on now about commit access for you/TW.net, wondering what branch to give you commit access to: https://github.com/libremesh/lime-packages/pull/254
- LiMeApp
- https://github.com/libremesh/lime-app
- format: JSON
- branch: "uhttp" until December-ish, then "develop".
3) "It could work as translatable page." Do you mean it could work without a parser?
4) Cool! I hope Amir and crew get that Telegram app to a usable release.
5) Where in TranslateWiki would we upload the screenshots? When you say "too large", what are the maximum dimensions of the image (like 80px by 200px)? What is the maximum file size?
6) Where is the code for the parser-generators that are currently in use on TW.net? We'd like to look at them to get a sense of what it would take to write another.
7) Any suggestions on how to internationalize this relatively simple web page interface, https://github.com/libremesh/chef ?
6) https://github.com/wikimedia/mediawiki-extensions-Translate/tree/master/ffs and docs in https://www.mediawiki.org/wiki/Help:Extension:Translate/File_format_support (likely somewhat outdated).
7) Maybe https://github.com/wikimedia/jquery.i18n ?
6) Thanks, we'll look at those.
7) The maintainer of the software to internationalize (Chef) says: "I'm currently not using jQuery in Chef but plain JavaScript. I'd rather keep it that way - if possible. Some quick searches resulted in https://github.com/eligrey/l10n.js/ - maybe thats already enough?"
Also, what are the howto booklets you mention in the subject? Our primary focus is on software user interfaces. [edit] We don't currently support ODT files. Some kind string extraction to another format would be needed. Are the booklets created so that they can be automatically generated from the translated texts (i.e. no hardcoded positionings with length restrictions)?
The HowTo booklets are a series of guides about the social, technical, and economic aspects of how to create and maintain a community network, with the LibreRouter as the example hardware and software. The idea is that each booklet will be laid out by hand after translating. This means that an automated workflow (as is used in software) is not our plan for the first three languages, and we would join TranslateWiki.net only for the software interfaces.
However, if anyone can suggest a workflow to create the booklets that aligns with the way TranslateWiki.net functions, we're interested to try it out since that could facilitate the translation of the booklets into many more languages. Perhaps the ODT parser from the Zanata translation management platform could be included in TranslateWiki.net, or perhaps we could use a different format. Or perhaps a bit of the BookType software used to create the books at Flossmanuals.net could be reused.
I haven't done that before. I am sure there are string extraction plugins for ODT. The problem is that usually booklets have quite tight positioning and size constraints. Doing the layout manually for many dozens of languages (and dealing with possibly frequent updates) doesn't scale. But a flexible or simple ODT file we could probably support if there is a suitable parser-generator we can integrate.
Hi Nike, any chance you can setup the repo for LibreMesh document translation this week? Following the thread at https://github.com/libremesh/lime-packages/issues/257#issuecomment-423850005