Hi to all,
some time ago we launched the TDE Weblate Translation Workspace - TWTW. The first step was integration for translating applications. This seems to be successful. That's why I'm preparing the second step - integration for translating desktop-style files.
Integration to translate desktop style files required several things that had to be prepared in advance. Now everything seems ready. However, before we move forward, I need some things to discuss with you:
--1. What is suitable for translating?
Gettext since version 0.19 includes support for desktop style files. This is great so we can easily create and update POT files. By default, for desktop files the keywords are: Name, GenericName, Comment, Icon and Keywords. For our needs we add Description, ExtraNames and X-TDE-Submenu.
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?
--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.
--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.
--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?
--Thank you for reading to the end!
As a reward, here's a link to a real demonstration of creating desktop files translated using PO files:
https://mirror.git.trinitydesktop.org/gitea/TDE/abakus/pulls/3
Cheers
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Hi Slavek, seem comments mixed below. Cheers Michele
--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.
Extra point: how about translation of strings in .ui files?
Cheers Michele
--------------------------------------------------------------------- To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On Tuesday 17 of March 2020 05:15:37 Michele Calgaro via trinity-devel wrote:
Hi Slavek, seem comments mixed below. Cheers Michele
--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.
There seems to be a consensus - I also discussed it with Chris.
--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.
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.
--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)
There seems to be a consensus - I also discussed it with Chris.
--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>
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.
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
On Tue, 17 Mar 2020 10:03:41 +0100 Slávek Banko slavek.banko@axis.cz wrote:
On Tuesday 17 of March 2020 05:15:37 Michele Calgaro via trinity-devel wrote:
--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>
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'.
Not going to chime in on the rest, since it has little to do with me, but I also vote for "translations". The problem with using "po" is that it doesn't make it clear what the files are unless you already know how the translation system works. Also, the meaning of "po" might become opaque if details like the file extension used by the system change, so "translations" is more future-proof.
E. Liddell
--------------------------------------------------------------------- To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On Tuesday 17 of March 2020 21:50:13 E. Liddell wrote:
On Tue, 17 Mar 2020 10:03:41 +0100
Slávek Banko slavek.banko@axis.cz wrote:
On Tuesday 17 of March 2020 05:15:37 Michele Calgaro via trinity-devel
wrote:
--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>
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'.
Not going to chime in on the rest, since it has little to do with me, but I also vote for "translations". The problem with using "po" is that it doesn't make it clear what the files are unless you already know how the translation system works. Also, the meaning of "po" might become opaque if details like the file extension used by the system change, so "translations" is more future-proof.
Very good reasoning, thank you! It seems that we have drawn a consensus here.
E. Liddell
Cheers
Hi all,
since the code into a common cmake module has been merged and we already have some cases of actual use, I will do some recap.
On Monday 16 of March 2020 20:23:19 Slávek Banko wrote:
Hi to all,
some time ago we launched the TDE Weblate Translation Workspace - TWTW. The first step was integration for translating applications. This seems to be successful. That's why I'm preparing the second step - integration for translating desktop-style files.
Integration to translate desktop style files required several things that had to be prepared in advance. Now everything seems ready. However, before we move forward, I need some things to discuss with you:
--1. What is suitable for translating?
Gettext since version 0.19 includes support for desktop style files. This is great so we can easily create and update POT files. By default, for desktop files the keywords are: Name, GenericName, Comment, Icon and Keywords. For our needs we add Description, ExtraNames and X-TDE-Submenu.
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?
Our view proved to be correct because in a newer version of gettext, Icon was removed from the keywords.
In any case, regardless of gettext, we now extract strings with our own CMake function, because by doing so we get the correct reference to the source file line, and besides, we add the variable name as a comment available to the translator.
--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.
Although there was a consensus on variant a), it turned out that it would be appropriate to choose different ways for different desktop files. For example, a) is appropriate for application icons, while c) may be appropriate for protocols. For comparison see:
https://mirror.git.trinitydesktop.org/gitea/TDE/abakus/commit/a1a48db571e6fa... https://mirror.git.trinitydesktop.org/gitea/TDE/tdeio-apt/pulls/3
--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.
There was a consensus on variant 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?
Here was a consensus on the layout:
translations/desktop_files/<desktop-name>/<desktop-name>.pot translations/desktop_files/<desktop-name>/<lang>.po translations/messages/catalog/catalog.pot translations/messages/catalog/<lang>.po
There may be a simplified variant for messages if the application contains a single catalog:
translations/messages/catalog.pot translations/messages/<lang>.po
Similarly, if an application contains multiple desktop files for which it makes sense to be merged into one catalog:
translations/desktop_files/<catalog-desktops>.pot translations/desktop_files/<lang>.po
--Thank you for reading to the end!
As a reward, here's a link to a real demonstration of creating desktop files translated using PO files:
https://mirror.git.trinitydesktop.org/gitea/TDE/abakus/pulls/3
Cheers
Thank you for your suggestions and ideas.
Cheers
Hi
16.03.20 21:23, Slávek Banko wrote:
some time ago we launched the TDE Weblate Translation Workspace - TWTW. The first step was integration for translating applications. This seems to be successful.
There impossible to append a new language to an application.
I have tried that for yakuake and tdesvn for Ukrainian and get whether the Gate Timeout or:
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Regards, Roman
--------------------------------------------------------------------- To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On Wednesday 08 of April 2020 16:35:40 Roman Savochenko wrote:
Hi
16.03.20 21:23, Slávek Banko wrote:
some time ago we launched the TDE Weblate Translation Workspace - TWTW. The first step was integration for translating applications. This seems to be successful.
There impossible to append a new language to an application.
I have tried that for yakuake and tdesvn for Ukrainian and get whether the Gate Timeout or:
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Regards, Roman
Hi Roman,
yes, this problem is known, but unfortunately the fix probably may have to wait for Weblate 4.0. See:
https://github.com/WeblateOrg/weblate/issues/3664
In any case, the translation for the new language is successfully added to the git repository, there I just need to unblock the loading of the new translation into Weblate. It depends on how quickly I notice the blocked new translations. Yakuake translation is already available for you:
https://mirror.git.trinitydesktop.org/weblate/projects/applications/yakuake/...
Cheers
-
E. Liddell -
Michele Calgaro via trinity-devel -
Roman Savochenko -
Slávek Banko