I've been trying to make a simple text editor using QT Creator. This text editor has a translatable UI that supports 3 languages: English, Spanish, and Portuguese.
My problem is that every time I run lupdate, string literals in my code that are tagged as translatable (i.e. enclosed in tr() ) are parsed and can be edited and translated using QLinguist. However, strings that are part of QObjects (E.g. ButtonText for QFileDialog are not parsed. Am I missing some procedure in order for lupdate to parse these strings?
void PeterTextEditor::on_actionOpen_triggered()
{
QString fileName = QFileDialog::getOpenFileName(this, tr("Open Document"), QDir::currentPath(),
tr("Text documents (*.txt)"), 0, QFileDialog::DontUseNativeDialog);
if (fileName.isNull())
return;
if ( m_fileName.isNull() && !isWindowModified() )
{
loadFile(fileName);
return;
}
else
{
PeterTextEditor * openFile = new PeterTextEditor( fileName );
openFile->show();
openFile->setAttribute(Qt::WA_DeleteOnClose);
}
}
In above example tr("Open Document") would be parsed, but QFileDialog has QButton and QLabel objects with strings for button text and label text.These are not parsed. I would like these to be parsed so I could add translations using QLinguist.
All compiled translation files (*.qm) should be in the /translations directory and you would load them as shown in QFileDialog localization.
Unfortunately, the Qt libraries don't come with all translations for all languages, and, not all the translations supplied are complete.
For the version that I have (Qt 5.2.1), there is a Spanish translation(qt_es.qm) of the libraries but there are many strings that have not been translated yet, and there is no translation file for Portuguese(qt_pt.qm).
The translation of Qt to other languages is an ongoing project so I suggest you search the web and/or other forums to see if anyone has got updated files you can use.
If you cannot find any, and your Spanish translation is missing a couple of strings you need, you can file the source extraction files(*.ts) in the /Src/qttranslations/translations directory. Unfortunately, you probably will find only one for Spanish.
If you're willing to start a Portuguese translation, you can extract all the necessary strings you want by running lupdate on the /Src/qtbase/qtbase.pro file.
Related
I have recently adding a fix for atom-script package to resolve garbled text output in compile&run Java code in non-English Windows environment. (Issue #1166, PR #2471)
After this, now in release script package 3.32.1, javac has options -J-Dfile.encoding=UTF-8 and -encoding UTF-8 both. (diff is here) I have just realized that it is better to provide actual encoding of the current active editor which holds the target source code for -encoding option. After some research, I have learnt that the encoding can be acquired by
atom.workspace.getActiveTextEditor().getEncoding()
but, after I have tested in Japanese edition Windows, it returns shiftjis and this is not valid encoding name for javac command line option. (It should be MS932, SJIS or something similar.) I have no idea where I can get this type of encoding names without writing large conversion table for all possible encoding names. Is there any good utility for such purpose?
EDIT:
For demonstrating what I have supposed to do, I have created branch on my fork. Diff is here.
Getting current source code editor encoding by
const fileEncoding = getJavaTextEncodingName(atom.workspace.getActiveTextEditor().getEncoding())
and pass it to javac via
const cmd = `javac -encoding ${fileEncoding} -J-Dfile.encoding=UTF-8 -Xlint -sourcepath '${sourcePath}' -d '${tempFolder}' '${filepath}' && java -Dfile.encoding=UTF-8 -cp '${tempFolder}' ${classPackages}${className}`
And, function "getJavaTextEncodingName()" is the core of the question.
function getJavaTextEncodingName(atomTextEncodingName) {
switch (atomTextEncodingName) {
case "shiftjis" :
return "MS932"
}
return "UTF-8"
}
It is obvious that this is converting "shiftjis" to "MS932" but, it is not so beautiful if we implement all possible encoding name conversions here, so I am seeking better alternative.
I have a Qt program which was developed on Linux. In it are some user settings which are parsed from a config file. Of course, the users don't tend to have that config file during the first launch and we want things to work even if it isn't present, so a copy of the sensible defaults is stored in a resource text file, which is in the same format as the on-disk version would be.
I've run into an annoyance when running on windows...
The resources have had their "\n" line endings all converted to "\r\n" somewhere along the line! I'd really prefer to not have to alter the parsers to optionally accept more than one type of newline.
Is there a way to tell cmake to tell the Qt resource compiler to not do the conversion by passing a flag or similar?
EDIT: To clarify what's going on, I'll explain all of the little details of why I think qrc is adding the newlines...
First, I have a .qrc file which looks roughly like this:
<RCC>
<qresource prefix="/">
<file>res/DefaultSettings.txt</file>
</qresource>
</RCC>
It is added to the executable via cmake using code like this:
qt5_add_resources(QRC_SOURCES
resource.qrc
)
and
add_executable(my_project
resource.qrc
main.cpp
)
finally, it is being loaded with code like this:
QByteArray loadResource(const QString &resource) {
QResource res(resource);
if(!res.isValid()) {
qFatal("Failed to load internal resource");
}
// don't copy the data, if it's uncompressed, we can deal with it in place
auto defaults = QByteArray::fromRawData(reinterpret_cast<const char *>(res.data()), res.size());
if(res.isCompressed()) {
defaults = qUncompress(defaults);
}
// NOTE: at this point, using a debugger, I observe
// "\r\n" newlines in the defaults byte array
return defaults;
}
If by "resource" text file you mean a binary resource stored in the executable via qrc, then no: qrc will never alter the files - it doesn't discriminate between binary and text resources, it's all binary as far as it's concerned. Version control systems such as git may do that on checkin/checkout, though. You may also be reading the file using APIs that convert line endings. You'd ideally want to have a reproducer that outputs the file, and then another one that uses qrc to embed the file and then demonstrate the changed line endings.
I'm trying to read and edit a Desktop Entry .desktop file using Qt QSettings. The problem is that these files contain keys with multiple values separated by semicolon ;. I tried reading these as QStringList but no luck. I only get the first value. For example:
Keywords=disc;cdrom;dvd;burn;audio;video;
Categories=GTK;GNOME;AudioVideo;Audio;Video;DiscBurning;
MimeType=application/x-cd-image;application/x-cdrdao-toc;application/x-cue;application/x-toc;audio/x-scpls;audio/x-ms-asx;audio/x-mp3-playlist;audio/x-mpegurl;application/x-brasero;x-content/audio-cdda;x-content/video-dvd;x-content/video-vcd;x-content/video-svcd;x-content/image-picturecd;
Getting the values with:
settings.value("Desktop Entry/MimeType").toStringList();
settings.value("Desktop Entry/MimeType").toString();
returns only the first value (in my example: disc, GTK or application/x-cd-image).
How to I return the full value from those keys? And how do I write it back using QSettings?
Update (first attempt was completely useless)
Variant 1
QMap<QString, QString> settings;
QFile inFile("<input filename.ini>");
if(inFile.open(QIODevice::ReadOnly))
{
QTextStream in(&inFile);
while (!in.atEnd())
{
QString line = in.readLine();
QStringList linelist = line.split("=");
settings[linelist[0]] = linelist[1];
}
}
Variant 2
use QSettings::registerFormat().
This is probably the only "clean" way to do it with QSettings. The advantage is that you can register it with the .desktop extension. You'll have to write a pair of ReadFunc() and WriteFunc() functions.
I think you can't do it. QSettings has certain interpretation of .ini file format, which is very close to Windows interpretation, and is not meant for generic parsing. Semicolon starts a comment, and apparently QSettings allows comment after value until end of line, and AFAIK there's no way around it.
You need to find a different library to handle .desktop files, or implement one yourself.
I'm porting a Qt4 project to Qt5 (Qt 5.4.1 + VS2013), the project have some string translations. The source file is UTF-8 encoded. But today I found the piece of code won't work (They all worked well in Qt4).
this->paraList.push_back( QPair<QString,QString>( QString(tr("℃:")), QString(tr("Ω")) ) );
'paraList' is a QList, and the strings in it finally shown in a QTableWidget. They both show correctly in QLiguist, but when my application run, the centigrade symbol and the Ohm symbol don't be translated correctly, as below
But all other strings are translated correctly. My locale is zh_CN. Why these two characters are so special?
Problem is encoding. You are using non ASCII characters as translation pattern. There was some change in Qt5 how c-strings are converted (I don't remember details) and I'm suspecting this might be a problem.
Try use trUtf8 this should fix the problem.
I am writing a qt application, with the goal of it being portable to the 3 major operating systems.
I am using QFileDialog to select a folder, and then adding it to a QListWidget. However the folder name is being returned as E:/media even though I am on Windows. I would want it to return E:\media
I could use a simple string replace, but then on Linux/Mac it would look weird to have \home\user\Documents
My code if it helps:
void LibrariesForm::on_addButton_clicked()
{
QString dir = QFileDialog::getExistingDirectory(this, tr("Select Folder"), "/", QFileDialog::ShowDirsOnly);
if (dir.isNull() == true)
{
return;
}
ui->librariesList->addItem(new QListWidgetItem(dir, ui->librariesList, 0));
}
I guess you are looking for QDir::toNativeSeparators().
If you use the string just internally, you don't need to convert slashes to backslashes. Qt's classes work with linux-style pathes, too. If you want a "pretty printed" string, take Jérôme's answer. :)