avoiding the use of hard-coded strings

mzimmers

Hi all -

I'm getting to the point in my application development where it would be advisable to replace my hard-coded strings (like for QML Labels) with something that can be easily changed by a non-developer. It's perfectly fine if this is done at build time.

I'm using Qt 6.5.3, and am not using Designer for anything.

How have you accomplished this in your projects?

afalsa

Hello!

I usually use a Format.qml ( i like this filename) singleton in QML. I dont know how this impact in performance but at least for now i am happy.

I would like to see other people's feedback as well

//Format.qml
pragma Singleton

import QtQuick

QtObject {
    readonly property string aboutScreen_author: "Afalsa"
}

Christian Ehrlicher

See https://doc.qt.io/qt-6/i18n-source-translation.html

mzimmers

@afalsa that's definitely a very good start. I'm wondering if this could be expanded upon, perhaps by using something analogous to this (except for QML):

configure_file (
    "${CMAKE_SOURCE_DIR}/versionnumber.h.in"
    "${CMAKE_CURRENT_BINARY_DIR}/versionnumber.h"
)

@Christian-Ehrlicher your suggestion is spot-on, as I will need to allow for translation to French and Spanish, to support North American markets. It appears that the qsTr() function works with properties defined in QtObject, so that's good news.

// StringLiterals.qml
configure_file (
    "${CMAKE_SOURCE_DIR}/versionnumber.h.in"
    "${CMAKE_CURRENT_BINARY_DIR}/versionnumber.h"
)

// using in another .qml file
TabButtonCustom {
	id: homeButton
	buttonIcon: "qrc:/icons/Home.svg"
	buttonText: qsTr(StringLiterals.homeTabButton)

But, I'm not sure how the use of the translation tools assists with the question I posed. Or, were you just thinking ahead?

Thanks...

SGaist

Hi,

If I am understanding things correctly, your end goal is to make your application translatable. You can either use one language throughout your code (usually English) or use translation by ID. You can then create translation files (or your users can) and load them from within your application.

mzimmers

@SGaist the ability to perform translation is my goal, though that wasn't the purpose of this topic. I'm trying to determine how best to put all of my labels (using the term generically) into a single location that can be easily modified by a non-programmer. The goal would be to have no hard-coded strings in my code; they'd all reside in some file that could be altered by a technical writer or someone else.

And again, it's not a problem if these changes require a rebuild; I'm not looking for something dynamic.

Christian Ehrlicher

@mzimmers said in avoiding the use of hard-coded strings:

The goal would be to have no hard-coded strings in my code; they'd all reside in some file that could be altered by a technical writer or someone else.

That's what translation files are made for...

SimonSchroeder

@mzimmers said in avoiding the use of hard-coded strings:

I'm trying to determine how best to put all of my labels (using the term generically) into a single location that can be easily modified by a non-programmer. The goal would be to have no hard-coded strings in my code; they'd all reside in some file that could be altered by a technical writer or someone else.

Even if your original labels are written down in English you can still have an English translation. (We do use English translations just for plurals. There is a command to just extract entries containing %n.) Translatable strings can also have an additional comment/description. This can help to clarify (and disambiguate) what you actually meant. Maybe use something to make it clear that a string needs still translation, e.g. instead of using the string My label use something like >>>MY LABEL<<< instead. This makes it easy to spot string not yet translated to English. Or use the variable name as the string to be translated (camelCase or snake_case would be easy to spot as well). Your English "translation" would be the single file for your technical writer.

jipox60120

This post is deleted!