In addition to the comments below, there is a note on all translations:
The CMake code used works well, but as you can see in tde_add_project_translations, we now take into account the variable LINGUAS to influence what translations will be installed. This is mainly used by distributions that build from the source code instead of binary packages. We could consider the way to use tde_add_project_translations to make the behavior identical. This could be achieved for plugins when the translations were placed in a subdirectory according to the name of the generated file. For example plugins/alsa-sound/po/tderadio-alsa-sound/.... Such a location would allow easy use of macro tde_add_project_translations and thus gain the same behavior. For the translation of the application as such, this macro can be used immediately, without the need to change the location.
In addition to the comments below, there is a note on all translations:
The CMake code used works well, but as you can see in `tde_add_project_translations`, we now take into account the variable `LINGUAS` to influence what translations will be installed. This is mainly used by distributions that build from the source code instead of binary packages. We could consider the way to use `tde_add_project_translations` to make the behavior identical. This could be achieved for plugins when the translations were placed in a subdirectory according to the name of the generated file. For example `plugins/alsa-sound/po/tderadio-alsa-sound/...`. Such a location would allow easy use of macro `tde_add_project_translations` and thus gain the same behavior. For the translation of the application as such, this macro can be used immediately, without the need to change the location.
It is strange that the choice for the OSS module is like BUILD_..., while the choises that relate to other modules such as ALSA and LIRC are like WITH_.... There it makes sense that the choice is BUILD_..._PLUGIN, but it should also be for ALSA and LIRC.
It is strange that the choice for the OSS module is like `BUILD_...`, while the choises that relate to other modules such as ALSA and LIRC are like `WITH_...`. There it makes sense that the choice is `BUILD_..._PLUGIN`, but it should also be for ALSA and LIRC.
To install translations, we should take into account the variable LINGUAS. Therefore, either we have to add its processing to CMake rules in all plugins, such as is in tde_add_project_translations macro or change the location of translations in plugins, as mentioned in the previous review.
To install translations, we **should** take into account the variable `LINGUAS`. Therefore, either we have to add its processing to CMake rules in all plugins, such as is in `tde_add_project_translations` macro or change the location of translations in plugins, as mentioned in the previous review.
To properly use a variable LINGUAS for plugins translations (and convert-presets), one of the following is needed:
Change the translation location so that they are in the subfolder by name of the target file – for example plugins/alsa-sound/po/tderadio-alsa-sound/, and then can be used macro tde_add_project_translations().
Edit the CMakeLists.txt in all plugins to include the processing of variable LINGUAS such as in tde_add_project_translations – for example in plugins/alsa-sound/po:
To properly use a variable `LINGUAS` for plugins translations (and `convert-presets`), one of the following is needed:
1. Change the translation location so that they are in the subfolder by name of the target file – for example `plugins/alsa-sound/po/tderadio-alsa-sound/`, and then can be used macro `tde_add_project_translations()`.
2. Edit the CMakeLists.txt in all plugins to include the processing of variable `LINGUAS` such as in `tde_add_project_translations` – for example in `plugins/alsa-sound/po`:
```
file( GLOB po_files RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} *.po )
string( REGEX REPLACE "[ \r\n\t]+" ";" _linguas "$ENV{LINGUAS}" )
foreach( _po ${po_files} )
get_filename_component( _lang ${_po} NAME_WE )
if( "${_linguas}" MATCHES "^;*$" OR ";${_linguas};" MATCHES ";${_lang};" )
tde_create_translation( FILES ${_po} LANG ${_lang} OUTPUT_NAME tderadio-alsa-sound )
endif( )
endforeach( )
```
Thanks for the feedback @SlavekB. PR updated as per option 1. I have made a separate commit since moving files around also affects makefiles.
Yes, it makes sense and it looks good. The last small thing remains – adjust all CMakeL10n rules and add / for all the names of the catalogs. For example, CATALOG "tderadio-alsa-sound" change to CATALOG "tderdio-alsa-sound/". This ensures that the POT files will be generated into the newly created subfolder.
> Thanks for the feedback @SlavekB. PR updated as per option 1. I have made a separate commit since moving files around also affects makefiles.
Yes, it makes sense and it looks good. The last small thing remains – adjust all CMakeL10n rules and add `/` for all the names of the catalogs. For example, `CATALOG "tderadio-alsa-sound"` change to `CATALOG "tderdio-alsa-sound/"`. This ensures that the `POT` files will be generated into the newly created subfolder.
Thanks for the feedback @SlavekB. PR updated as per option 1. I have made a separate commit since moving files around also affects makefiles.
Oh, I forgot one thing – to avoid losing history in TWTW, we need translations and catalogs first copy to a new location, then edit TWTW configuration and only then remove files from the original location.
> Thanks for the feedback @SlavekB. PR updated as per option 1. I have made a separate commit since moving files around also affects makefiles.
Oh, I forgot one thing – to avoid losing history in TWTW, we need translations and catalogs first copy to a new location, then edit TWTW configuration and only then remove files from the original location.
Yes, it makes sense and it looks good. The last small thing remains – adjust all CMakeL10n rules and add / for all the names of the catalogs. For example, CATALOG "tderadio-alsa-sound" change to CATALOG "tderdio-alsa-sound/". This ensures that the POT files will be generated into the newly created subfolder.
yeah, my bad for not testing that part :-(
Oh, I forgot one thing – to avoid losing history in TWTW, we need translations and catalogs first copy to a new location, then edit TWTW configuration and only then remove files from the original location.
yes, I may actually do the move of the files first as a separate task, then the cmake conversion on top of that. I will have a look later.
> Yes, it makes sense and it looks good. The last small thing remains – adjust all CMakeL10n rules and add `/` for all the names of the catalogs. For example, `CATALOG "tderadio-alsa-sound"` change to `CATALOG "tderdio-alsa-sound/"`. This ensures that the `POT` files will be generated into the newly created subfolder.
yeah, my bad for not testing that part :-(
> Oh, I forgot one thing – to avoid losing history in TWTW, we need translations and catalogs first copy to a new location, then edit TWTW configuration and only then remove files from the original location.
yes, I may actually do the move of the files first as a separate task, then the cmake conversion on top of that. I will have a look later.
As per title. Builds and seems to works fine.
In DEB distros, to be built with TDE/tde-packaging#126
892ac39067
to0ce973505b
2 years agoIn addition to the comments below, there is a note on all translations:
The CMake code used works well, but as you can see in
tde_add_project_translations
, we now take into account the variableLINGUAS
to influence what translations will be installed. This is mainly used by distributions that build from the source code instead of binary packages. We could consider the way to usetde_add_project_translations
to make the behavior identical. This could be achieved for plugins when the translations were placed in a subdirectory according to the name of the generated file. For exampleplugins/alsa-sound/po/tderadio-alsa-sound/...
. Such a location would allow easy use of macrotde_add_project_translations
and thus gain the same behavior. For the translation of the application as such, this macro can be used immediately, without the need to change the location.option( BUILD_ALL "Build all" ON )
option( BUILD_DOC "Build documentation" ${BUILD_ALL} )
option( BUILD_OSS_PLUGIN "Build OSS plugin" ${BUILD_ALL} )
It is strange that the choice for the OSS module is like
BUILD_...
, while the choises that relate to other modules such as ALSA and LIRC are likeWITH_...
. There it makes sense that the choice isBUILD_..._PLUGIN
, but it should also be for ALSA and LIRC.if( WITH_ALSA )
find_package( ALSA )
if( NOT ALSA_FOUND )
message(FATAL_ERROR "\nalsa support is requested, but was not found on your system" )
Instead of
message( FATAL_ERROR ... )
we normally use macrotde_message_fatal( ... )
– see a few lines below.I will adjust the code.
For info, this was taken from some other TDE modules, so we probably need to do anoverall review at some point.
if( WITH_LIRC )
pkg_search_module( LIRC lirc )
if( NOT LIRC_FOUND )
message(FATAL_ERROR "\nlirc support is requested, but was not found on your system" )
Instead of
message( FATAL_ERROR ... )
we normally use macrotde_message_fatal( ... )
– see a few lines above or below.pkg_search_module( SNDFILE sndfile )
if( NOT SNDFILE_FOUND )
tde_message_fatal( "sndfile is requested, but was not found on your system" )
sndfile
seems to be required, not requested.Good point, will rephrase the comment
#cmakedefine WORDS_BIGENDIAN @WORDS_BIGENDIAN@
// Defined if ALSA support found
#cmakedefine HAVE_ALSA
This is not used because instead of
HAVE_ALSA
is used in the meaning ofBUILD_ALSA
. See the first comment.#cmakedefine HAVE_LAME
// Defined if LIRC support found
#cmakedefine HAVE_LIRC
This is not used because instead of
HAVE_LIRC
is used in the meaning ofBUILD_LIRC
. See the first comment.recording-monitor.cpp encoder_mp3.cpp encoder_ogg.cpp encoder_pcm.cpp
LINK tderadio-shared ${LAME_LIBRARIES} ${OGG_LIBRARIES} ${VORBIS_LIBRARIES}
${VORBISFILE_LIBRARIES} ${VORBISENC_LIBRARIES} ${SNDFILE_LIBRARIES}
Incorrect indentation.
SOURCES
streaming.cpp streaming-configuration-ui.ui
streaming-configuration.cpp streaming-job.cpp
LINK tderadio-shared
In other cases there is an empty line in the same situation. Although it is not crucial, it seems good to be consistent.
##### other data
INSTALL(
FILES tderadio.desktop
It is advisable to use
tde_create_translated_desktop
, regardless of the translation usingpo
files is not yet ready.9d77233671
tob2f3b1c9de
2 years agoAll point addressed.
To install translations, we should take into account the variable
LINGUAS
. Therefore, either we have to add its processing to CMake rules in all plugins, such as is intde_add_project_translations
macro or change the location of translations in plugins, as mentioned in the previous review.tde_create_translated_desktop(
SOURCE tderadio.desktop
DESTINATION ${XDG_APPS_INSTALL_DIR}
The
XDG_APPS_INSTALL_DIR
path is default. Therefore, the call can be simplified to:file( GLOB _srcs RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} *.po )
if( _srcs )
tde_create_translation( LANG auto OUTPUT_NAME tderadio )
As I mentioned in the previous review, here instead of the whole proposed code can be used simply:
b2f3b1c9de
tobeeea5e6a6
2 years agoUpdated based on the feedback received.
To properly use a variable
LINGUAS
for plugins translations (andconvert-presets
), one of the following is needed:Change the translation location so that they are in the subfolder by name of the target file – for example
plugins/alsa-sound/po/tderadio-alsa-sound/
, and then can be used macrotde_add_project_translations()
.Edit the CMakeLists.txt in all plugins to include the processing of variable
LINGUAS
such as intde_add_project_translations
– for example inplugins/alsa-sound/po
:Thanks for the feedback @SlavekB. PR updated as per option 1. I have made a separate commit since moving files around also affects makefiles.
Yes, it makes sense and it looks good. The last small thing remains – adjust all CMakeL10n rules and add
/
for all the names of the catalogs. For example,CATALOG "tderadio-alsa-sound"
change toCATALOG "tderdio-alsa-sound/"
. This ensures that thePOT
files will be generated into the newly created subfolder.Oh, I forgot one thing – to avoid losing history in TWTW, we need translations and catalogs first copy to a new location, then edit TWTW configuration and only then remove files from the original location.
yeah, my bad for not testing that part :-(
yes, I may actually do the move of the files first as a separate task, then the cmake conversion on top of that. I will have a look later.
add_definitions (
-UTQT_NO_ASCII_CAST
Now I remembered that I saw
-UTQT_NO_ASCII_CAST
definition in the patch. Therefore, I did a test and it seems that this is not needed.ok, thanks for testing this out. I will update accordingly.
8e538efc5c
to19e25cb45c
2 years agoRebased on top of current master and issues mentioned above addressed.
19e25cb45c
to084a5f7462
2 years ago084a5f7462
tobc7518bdba
2 years agoEverything looks good.
bc7518bdba
into master 2 years agoReviewers
bc7518bdba
.