It could be useful to check the localization in a release build. But, currently, we can have key ID provided by the qtz pseudo-language only in a dev. build like beta versions (the ones which are installed under the name LibreOfficeDev). I suggest that the build of the qtz pseudo-language could be decided the same way than for all other languages by adding its code in the option --with-lang in the autogen.input file. Best regards. JBF
Forgot to set it as enhancement. Best regards. JBF
What would be the advantages of doing that? It would not be enabled for official builds, so one would have to build libreoffice oneself. But in that case one can just do a non-release build... IMHO the key "translations" are testing/debugging aid, therefore they do not belong to release builds.
(In reply to comment #2) > What would be the advantages of doing that? It would not be enabled for > official builds, so one would have to build libreoffice oneself. But in that > case one can just do a non-release build... I think that if qtz pseudo-language was available in official builds too, that would make debugging translations in x.y.z (z > 0) versions easier. > IMHO the key "translations" are testing/debugging aid, therefore they do not > belong to release builds. In fact we are always in testing period. When translations bugs are found in the integrated help by advanced users in x.y.0 or x.y.1 versions, it would be easier to find their exact locations with the keyID. It would be sufficient to say her: please install qtz language and give me the keyID. Actually it may be very complicated to explain how to go to a particular help page. On the other hand, it seems that dev builds with keyID are available only for betas which concerns only x.y.0 versions. Best regards. JBF
Since JBF has already provided the needed info, this should be set back to UNCONFIRMED. I agree that this enhancement request is reasonable, So I set it to NEW. There are always UI/help translation errors in release builds. KeyID is really helpful to locate strings quickly and help to speed-up localization. In fact, if you look at 4.3.0.1, many languages are not 100% translated. For 4.2.5.2 release, there are still many strings need translation improvements.
https://opengrok.libreoffice.org/xref/core/configure.ac?r=b43f0b02#13975
Christian, could we really to have qtz in release builds too?
+1 from me also for having KeyID in the release builds. It would be useful for translators and I don't really see any drawback in including it. Yes, it's a kind of testing tool, but these days LO also ships development tools in the release build (and I don't have any objections to that either).
I'll add that it would be also useful to enable "qtz" in the release builds of Help (offline and online), so that anyone who finds an error in Help could easily switch the language to qtz to see the associated KeyID.
I agree that it would be good to have the qtz (KeyID) language pack in the release builds, too. Not installed by default, but be present in the list of language packs that the user can choose to add to the standard installation. Users doing a standard installation will not even see it is present. It will only be seen by those who look for it (developers) and those users who choose to do a custom installation and look through the language list. If a user from the latter group tries it out, well, not harm done - the same user might out of curiosity try out a language pack in an foreign language pack, which is totally possible if you want. Put another way: Adding the possibility to install an ugly-but-useful-for-developers language pack will not take anything from anybody, but it will make things easier for developers. So I see an advantage and no drawbacks. Can anybody think of a good reason why NOT to include it as an option that can be chosen by installation in release builds?