17 Mar
2020
17 Mar
'20
9:03 a.m.
On Tuesday 17 of March 2020 05:15:37 Michele Calgaro via trinity-devel
wrote:
Yes, we've discussed it before. I also discussed it with Chris and always
option a) comes out as the right choice, although it represents a larger
number of PO files.
There seems to be a consensus - I also discussed it with Chris.
I have no objections to any of the options to use short 'po' and or
long 'translations'. The only important thing is that we find the
consensus and then unify it in all modules. Similarly to 'desktops'
× 'desktop_files'.
In any case, I object to the proposal
translations/desktop_files/<lang>/<all po files...> because this is not
technically possible. As I wrote above, both the tools - msgfmt (for
gettext >= 0.19) and intltool-merge expect all translations of one desktop
file to be in one directory, and the file names corresponds to the
language. Therefore there is a necessary layout
translations/desktop_files/<desktop_file>/<lang>.po
Both layout options are possible for 'messages'. But there is the question
of whether to use different layouts for desktop files and for messages
files?
Note: In any case, this does not apply to tde-i18n and koffice-i18n
modules, where it is always at the highest level sorting by language.
These modules will not contain translations of desktop files.
Hi Slavek,
seem comments mixed below.
Cheers
Michele
There seems to be a consensus - I also discussed it with Chris.
--1. What is suitable for translating?
Although the keyword list seems reasonable, I have doubts about
"Icon". The icon name is often the same as the application name. This
could result in the icon name being translated inadvertently.
What is your opinion?
I had the same doubt when looking at the abakus PR you prepared. I don't
think Icon needs to be translated.
--2. How to
structure translation templates?
If you worked in TWTW, you probably know that the translations here
are structured into two levels - project => component. Where the
component corresponds to one particular translation template. We used
the projects for the basic division - dependencies, main modules
(individual projects), libraries, applications.
The question is how to generate POT templates for desktop file
translations? Here are some fundamentally different options:
a) Create a separate POT template for each desktop file => advantage -
it will be very clear, disadvantage - there will be many new
components. However, each with a small number of strings.
b) Incorporate desktop files translations as part of existing POT
templates for individual components (applications) => advantage -
there will be only a few new components, disadvantage - there will be
less clarity, this may prevent correct translation of the strings in
the desktop file if the same string in another context is used inside
the application.
c) Merge templates of multiple desktop files into one common template
=> advantage - no too many new components arise, disadvantages same as
for b) with higher risk of collision of identical strings with
different context.
As we discussed on IRC earlier, it seems option a) is the only viable
one. Although I am not in favor of having hundreds of small .po files,
that seems to be the only solution that allows for context-dependent
translation of the same strings in different contexts.
--3. How to
structure components for desktop file translations?
If there will be a separate templates for translating desktop files,
then there are two possible ways to integrate them into TWTW:
a) Add as additional components to existing projects => advantages -
translations will be close to the applications to which they belong,
disadvantages - the number of components in projects will increase.
b) Create a separate project for all desktop file translations =>
advantages - no increase in the number of components in existing
projects, disadvantages - some TWTW checks will not be able to be
applied because the application and its desktop files will be
different projects.
Option a)
--4. How to
organize translation files in source git repositories?
Currently, the organizing of the translation files is inconsistent.
Therefore, it seems appropriate to harmonize the layout of directories
with translations.
Here are a few of the variations used: + po/<lang>.po +
po/<lang>/<app>.po + translations/<lang>/<app>.po +
translations/<lang>/messages/<app>.po
For desktop file translations, all languages are required to be
located in the same directory, named in accordance with the language.
For example:
+ po/desktops/<desktop-name>.pot +
po/desktops/<desktop-name>/<lang>.po
Do you prefer the directory name "po" or "translations"? In this
directory, it seems to me a good breakdown by purpose - "messages",
"desktops", because this will allow in the future to add "docs",
"manpages". The structure could look like this:
po/desktops/abakus.desktop.pot po/desktops/abakus.desktop/<lang>.po
po/messages/abakus.pot po/messages/abakus/<lang>.po
What is your opinion?
How about this?
translations/desktop_files/pot/<all pot files of the module>
translations/desktop_files/<lang>/<all po files of the module for the
language> translations/messages/pot/<all pot files of the module>
translations/messages/<lang>/<all po files of the module for the
language>
Additional point mentioned in abakus PR: in the pot file we are losing
the context of the string, for example if it is a GenericName or Name or
anything else. Would be better to add as part of the comment for each
string.
See comment at PR - xgettext does not allow it. We can try if the newer
version of gettext behaves differently... or make our own replacement tool
(cmake macro) for extracting strings from desktop files.
Extra point: how about translation of strings in .ui
files?
No need to worry, it has been resolved a long time ago - see the macros in
our TDEL10n cmake module that do much better work than the previously used
extractrc and extractattr tools.
Cheers
Michele
Cheers
--
Slávek