kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #13565
Re: a way to handle translations
On Fri, Jun 06, 2014 at 08:10:01AM +0200, jp charras wrote:
> Le 06/06/2014 01:18, Marco Ciampa a écrit :
> > Hello, hope topic not too boring for you serious devs ... :-)
> >
> > I am a translator and started to look at kicad because of many
> > untranslated strings in italian I saw in it. Looking at the translation
> > strings (in it.po file) I have seen that many are missing.
> > I mean that, for example, I see that "Open Text Editor" or "Open Project"
> > is not translated and is not present in kicad-doc.bzr/internat/it/kicad.po.
> >>From this fact a couple of questions:
> > - how is handled the translation update process in kicad?
> > - why not using po/POTFILES.in and leave the burden to intltool-update that
> > is made for this?
> >
> > TIA
> >
>
> Thanks for you interest about Kicad.
>
> Kicad uses .mo and .po files and the tool to build and maintain
> translation files is Poedit (multiplatform tool).
> Poedit is designed to easily maintain translations in applications using
> wxWidgets library (this is the case for Kicad).
> the kicad.po file is the file used by Poedit to manage translations, and
> the kicad.mo is the translation created by Poedit.
>
> Please, read the doc file GUI_Translation_HOWTO.pdf (in kicad sources),
> which explains how to maintain translations.
>
> You need the latest Kicad sources to build/maintain translations, but
> translation files are always fully outside sources.
I've always used emacs's po-mode for traslations and I thought
that poedit was only another poedit-or.
Now I see (after trying it) that it is in fact much more
than that: it handles po updates too so there is no need
of a separated updating tool.
I personally continue to use emacs for translations (habits are hard
to change...) and use poedit just for updating strings catalog.
A small note: IMHO the decision to keep documentation separated from
program logic brings to some (small?) problems. Poedit have to
have a sources catalog for translatable strings, as was with
intltool-update, to know were actual program sources are kept in
your local disk. It just keep it in the .po file
headers. Now translations are kept separated from the program,
in a different repository (why?), so software paths must be absolute. Of
course every contributor works in a different way with a different
OS etc. so this leads to that every contributor rewrites this path
to second to his/her personal taylored system. If these docs (that are
version dependent!) are kept into the main source tree, paths could be
relative (but I do not know how poedit handles
inter-platform dir-separator-char conversion, if any is in
place...). Anyway I will always prefer and suggest to
keep different functions separated (KISS) and have a (c)make driven
translation catalog update. That would open the door to a procedure that
can handle the automatic update of all language strings at every
recompilation, via intltool-update or other tools, enabling an
easier translation of all platform programs even by means of a web
translation platform.
PS: when I finished translating the strings, since doc source tree is not
mirrored into git, how is the preferred/best way to post the finished .po
file?
May I post it as an attached file here in this list or it is better in
another way?
I would perfer to commit directly into the repo though I am not used
to bazaar. If I can write to the repo directly I would
update all languages catalogs and strings, though manually. This could be
useful to check the translation progress for every foreign language after
string freeze and before the commit of a new stable release.
bye
PS: forgive my bad English, my Italian is much better... ;-)
--
Marco Ciampa
+--------------------+
| Linux User #78271 |
| FSFE fellow #364 |
+--------------------+
Follow ups
References