tde-devels March 2020

devels@trinitydesktop.org

4 participants
6 discussions

[trinity-devel] Desktop files translations

by Slávek Banko

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 -- Slávek

4 years, 7 months

[trinity-devel] R14.0.8 is coming soon

by Slávek Banko

Hi all, As developers, you are probably more involved, so you probably keep in mind that there is a plan for release R14.0.8 at the end of April. Therefore, only a small reminder: http://trinity-users.pearsoncomputing.net/?0::16857 Cheers -- Slávek

4 years, 7 months

[trinity-devel] pinentry-tqt

by deloptes

Hi, I just read the msg on TGW regarding gpg1 and recalled that we were discussing to introduce pinentry-tqt to TDE. I'm using it may be for an year now and it is perfect. Can we at least include it into the 14.1 branch? I was thinking it was done, but can not recall what or where happened. Might be it is still in bugzilla. Any bells or something from deep memory? regards --------------------------------------------------------------------- To unsubscribe, e-mail: trinity-devel-unsubscribe(a)lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help(a)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

4 years, 8 months

[trinity-devel] Embedded metadata × reproducible builds

by Slávek Banko

Hi all, as you probably know, if tdelibs are compiled with elf editor support (WITH_ELFICON), the application icon, TDE information and git repository information are embedded into libraries and binaries during CMake build. This data, on the one hand, provides user convenience - better to see the application icon than the general binaries icon. On the other hand, they provide information to developers - for example, when reporting creashes. It is possible that you have also heard about the activity Reproducible builds, which seems to us as a very good idea. See: https://reproducible-builds.org/ https://wiki.debian.org/ReproducibleBuilds Currently, the metadata that are embedded has a Compilation Date/Time entry. This is set to the current date and time at the time of building the binary package. And this is a problem because it makes it impossible to achieve reproducible builds. My suggestion is that next to the ".tdescmmodule" and ".tdescmrevision" files we could have a ".tdescmdatetime" file containing the git commit date and/or a ".tdepackagedatetime" file containing the date the source package was created for distribution. For embedded metadata, this fixed time would be used instead of variable time. What is your opinion? Cheers -- Slávek

4 years, 8 months

[trinity-devel] How to easily check build configuration

by deloptes

Hi, I am wondering if there is a way to check how packages were configured before building. When you run automatic build of TDE the information how a package was build is saved in the xxx.build file, but there are so many and to me it does not look like consistent output. I want to know if some configuration options were omitted automatically because some dev packages or libraries are missing. For example tdebindings reported that c# (recommended mono) is missing and therefore bindings for c# will not be build, but it builds the rest. How can I collect and examine this? thank and regards --------------------------------------------------------------------- To unsubscribe, e-mail: trinity-devel-unsubscribe(a)lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help(a)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

4 years, 8 months

[trinity-devel] kpowersave cmake object 8668335711fa13cec276552d75bfbb4285c7edb0 missing

by deloptes

Hi, another and hopefully my last question regarding the git repo. What should I do to correct it ==========./applications/kpowersave=========== Fetching submodule admin Fetching submodule cmake Already up to date. error: Server does not allow request for unadvertised object 8668335711fa13cec276552d75bfbb4285c7edb0 Fetched in submodule path 'cmake', but it did not contain 8668335711fa13cec276552d75bfbb4285c7edb0. Direct fetching of that commit failed. --------------------------------------------------------------------- To unsubscribe, e-mail: trinity-devel-unsubscribe(a)lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help(a)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

4 years, 8 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels March 2020