for translation management of the software interfaces
related to the LibreRouter project. If you have an opinion, speak by this Friday, October
20, even just "I care about this but don't have time to respond until next
week".
Developers, please read this, at least a little:
I haven't found the translation files for the following software. If you know, please
tell me:
- LibreMap
- WiFi Calling (app and server)
- LimeBuild / Cooker / SDK
- LibreNet6
- Pitbull
- LibreServer
cheers,
Patrick
El 13 de octubre de 2017 17:10:18 GMT-05:00, Patricio Gibbs
<patricio(a)altermundi.net> escribió:
Hi, Patrick/Patricio/Pato here, coordinating the
translation of the
software and documentation related to the LibreRouter. I write to the
list to let folks know what's going on and open for feedback about the
current plan.
After considering various options of what platform to use for
translation management, I think the most appropriate is
TranslateWiki.net, because it means:
- someone else takes care of the hosting,
- is costs us no money (though we could donate some if they need it and
if our budget allows),
- we share the platform with other open source software projects,
- we join a platform that already has an active community of
translators in many languages,
- the software running the platform is stable and has been in
production use to translate the MediaWiki interface for some time,
- and all of that together means that once we get our process with
TranslateWiki.net going well, it could run easily for years and allow
the addition of new languages easily.
Joining
TranslateWiki.net requires giving direct push commit access to
at least one
TranslateWiki.net admin, so that new translations get
committed quickly and thus new translations make it into software
releases as quickly as practical.
I hope that we can get a relationship with
TranslateWiki.net setup and
translation underway before the end of October, so if you have any
ideas, questions, objections, please respond in the next few days.
[A shortcoming of
TranslateWiki.net is that it can't handle ODT files,
which is the current format for the documentation booklets. We'll
either find a way to convert the booklet text into a compatible format,
or we'll use a different tool (perhaps Zanata) that works well with the
current creation process of the booklets. More about documentation
translation in another email.]
For those curious about
TranslateWiki.net, see this page
https://translatewiki.net/wiki/Translating:New_project
For those who want to understand i18n and l10n from a software
development perspective (that's internationalization and localization),
see:
https://translatewiki.net/wiki/Translating:Localisation_for_developers
*Developers, please read that, at least a little.*
To see our conversation so far with
TranslateWiki.net:
https://translatewiki.net/wiki/Support#LibreRouter:_new_project_with_softwa…
Once a software has an i18n and l10n structure setup, we add a "qqq"
language file for the documentation about each string that will be
translated. More details about that here:
https://www.mediawiki.org/wiki/Localisation#Message_documentation
SOFTWARE:
LibreMesh uses Gettext, and is translated into Spanish:
https://github.com/libremesh/lime-packages/blob/develop/packages/lime-webui…
LimeApp uses a JSON format, and is translated into Spanish:
https://github.com/libremesh/lime-app/tree/master/i18n/translations
Firmware Chef uses Gettext, and is translated into Spanish:
https://github.com/libremesh/alterchef/tree/master/altermeshfc/altermeshfc/…
I haven't yet found the locations of the translation files for the
following software, or confirmed whether the software even has
translation files:
- LibreMap
https://github.com/libremap
- WiFi Calling (app and server)
-- repository unknown
- LimeBuild / Cooker / SDK
https://github.com/libremesh/lime-sdk
- LibreNet6
-- repository unknown
- Pitbull captive portal
https://github.com/libremesh/pitbull
- LibreServer (more complex since it's an entire GNU/Linux distro,
though maybe there's a central admin interface)
-- repository unknown
Over the long term, we might consider changing the i18n/l10n format of
some of the software to a format preferred by
TranslateWiki.net, as
described in this note from
TranslateWiki.net:
"Use of key-based file formats is preferred, like Java properties and
Ruby-style YAML. Other supported file formats are PHP arrays, PHP
variables and Gettext." For now, making such a change is not priority
and probably not within our capacity. Pau pointed out to me that in
LibreMesh, there's a little program that pulls strings out of the code
and puts them in the translation files, and that a similar function
would be necessary if we changed to a different format. We could ask at
TranslateWiki.net if they know of such programs.
~ Patrick