23 Oct
2017
23 Oct
'17
12:56 a.m.
The flow for creating, translating, and publishing documents depends on what kind of
document. For example, a book, a blog post, and a press release have different
requirements. What documents are you thinking about?
For the LibreRouter booklets, I asked some questions on Translatewiki.net and there's
a chance that with a little bit of coding, we could use that platform for ODT format
documents. See the conversation thread at
https://translatewiki.net/wiki/Thread:Support/LibreRouter:_new_project_with…
The incompatibility between those bullets and Translatewiki.net is that the booklets will
be laid out by hand in each language, so publishing in each new language isn't
automatic like it is with software. Translatewiki.net prefers projects with automatic
publishing in order to guarantee that the work done by translators reaches the public and
doesn't very stuck waiting for manual intervention.
That said, it may still be possible to adapt our booklet workflow and the
parser-generators on Translatewiki.net to create a flow that works for everyone. This
would be really nice! It would open up the booklets to translation by a large community of
open source translators in many languages.
A backup option is Zanata, which works with ODT files. We would have to do the translation
ourselves, since there's very little community there.
Another option for some documents is www.flossmanuals.net, a multilingual platform for
manuals related to open source projects and similar topics. It runs BookType, a software
created specifically from the needs of the FLOSS Manuals community. It has some
limitations, such as not being able to make sub chapters, but it's advantages are
many, including direct links to publishing sites that allow one to buy a printed copy of
any book on the site and the ability to make a custom book by remixing the chapters of any
of the books on the site.
Let's see if there's a way to work with Translatewiki.net.
Pato
El 20 de octubre de 2017 9:14:32 GMT-05:00, Nicolas Pace <nico(a)libre.ws> escribió:
We need to find a way of translating documents also.
It would be great if it is on the same platform, but if not finding
another one would be key.
Regards,
On Tue, 2017-10-17 at 22:56 -0500, Patricio Gibbs wrote:
> Tl;dr
> We plan to use translatewiki.net 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:
> https://translatewiki.net/wiki/Translating:Localisation_for_developer
> s
>
> 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
> @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_develop
> > ers
> > *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_wit
> > h_software_and_HowTo_booklets_54035
> >
> > 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/li
> > me-webui/po/es/lime-webui.po
> >
> > 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/alte
> > rmeshfc/locale
> >
> > 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
>
> _______________________________________________
> lime-users mailing list
> lime-users(a)lists.libremesh.org
> https://lists.libremesh.org/mailman/listinfo/lime-users