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/a1a48db571e6fa1c3ae94a22546548b87e497dd2 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 -- Slávek
Attachment:
signature.asc
Description: This is a digitally signed message part.
