I need to compile a .tex file twice with django_tex in order for the table of contents to load correctly. Is there a way to tell the interpreter in django_tex to run the compiler twice (I use pdflatex)??
Code:
\documentclass{article}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\begin{document}
\tableofcontents
\section{Introduction}
Introduction text.
\section{Second section}
Second section text.
\end{document}
django_tex seems to support latexmk, which will (amongst many other useful things, like running bibliography tools) automatically determine the required number of *tex runs.
To use this, you can follow the advice from https://github.com/weinbusch/django-tex/pull/5#issuecomment-447030408 and add
LATEX_INTERPRETER='latexmk -pdf'
to your settings.py.
Qt 5.15 introduces (at least I believe it is new to 5.15) .ts files, to allow for properly handling multi-locale text in an application. I'm updating an iOS Qt app from 5.X, where X knows nothing about .ts files. On startup, I'm getting a warning that indicates that there is an app-specific translation set (which is true), but that there is no translation for Qt's own text (things like warning text and dialog prompts). The documentation says, that these translations are in the Qt5 source directory (currently usually /tqtc-qt5) in the qtttranslations folder. Thus sayeth this doc https://doc.qt.io/qt-5/ios-platform-notes.html#application-assets. Examples show only app-unique text translations, not Qt's "built-in" text. So real quick, I'm going list my assumptions, so that they can be corrected or confirmed.
Qt has always had embedded text of its own, but 5.15 introduces a way to ensure that your multi-locale ready app has all the correctly translated "built-in" text available.
Only the app-writer knows what modules they are using, so it is the app-writer's responsibility to specify which set of translations are added to the app's resources for handling different locales. (per this document - https://doc.qt.io/qt-5/qmake-variable-reference.html#translations)
According to the above two docs, for example, if I use basic Qt functionality and QML, AND I have a single app with tier-one language support for, say, English, German, and French, it appears that my app's .pro file should include something like
TRANSLATIONS += <path_to_qt5>/qttranslations/qtbase_en.ts
TRANSLATIONS += <path_to_qt5>/qttranslations/qtbase_de.ts
TRANSLATIONS += <path_to_qt5>/qttranslations/qtbase_fr.ts
TRANSLATIONS += <path_to_qt5>/qttranslations/qtdeclarative_en.ts
TRANSLATIONS += <path_to_qt5>/qttranslations/qtdeclarative_de.ts
TRANSLATIONS += <path_to_qt5>/qttranslations/qtdeclarative_fr.ts
CONFIG += lrelease embed_translations
I've traced though the Qt source in the debugger to the point where it is complaining about the missing translations. It is looking for qt*_*.qm, where the first wildcard is your module ("base", "declarative", etc) and the second is your two-letter language code. So, should I be explicitly adding .qm files as resources in my iOS bundle, or is TRANSLATIONS += foo_ln.ts implicitly doing this embedding in response to CONFIG += lrelease embed_translations. One things is certain: right now, my naive porting of an older .pro file does nothing with respect the TRANSLATIONS property AND Qt is cranky about the missing .qm files in my bundle. It's a warning, not a critical fail, so I assume in a pinch, it would put up US english text, which seems to be the baseline for translations and is embedded in the source (not the bundle) by default. Do my example additions to the .pro file in point 3 above seem sufficient, or is there more to do? Or is there less to do? Is there a .pro directive that I've missed in the docs that says "do the right thing with international translations of Qt-inherent strings"? There is in a addition to the listed .ts files a "qt_*.ts" file set. Is this just everything whether I need it or not, for lazy people who don't care about lugging around a few extra strings? Finally, there is also EXTRA_TRANSLATIONS which is like TRANSLATIONS, only it does not go through the lupdate during the build. Now I'm pretty unclear on the function of lupdate relative to lrelease, but is it the case that one is for "stock" Qt strings, and the other for App-specific translations (because they may be "updated" due to changes during development)? The semantics just don't make sense to me right now, nor do my responsibilities to handle these matters in the "right" way.
I'd like to answer my own question because it turns out many of the above assumptions were just wrong, and it took deeper dives into the source code and the debugger to get my head straight, but now I have Wisdom. The documents I was reading was about how to include raw translation files "(.ts files)" into an app being built with qmake. As is typical with Qt, building with qmake or Qt Creator solves most of your problems automatically, with your part being to provide only the small amount of specification needed to execute your app. The app I'm working on however is monstrously huge, old, and overly-complicated, so I spend a lot of time hunting down the most obscure Qt and CMake features to cobble this Frankenstein's monster of an app together. The problem I was trying to solve is simply providing to Qt its own text localization files for a multi-locale app. The app-specific ones were fine, but Qt was wagging its finger at me and complaining that it couldn't find its own. So the .ts files it turns out are not a thing for this kind of task - they are simply part of the pipeline of getting data from a translation house in a consumable form. During Qt's own configure and build (yes we build Qt from source), it handles the compiling of raw .ts files into .qm files, suitable for use by the framework's translator objects. Those are all just sitting in qtbase/translations ready to be integrated into the app installation. The problem was that we (the group who developed this app long ago and which I am now reviving) didn't handle the iOS case. This is a special case that requires some choices. You can put translation files in the app's bundle at a specific path, you can home-brew some exotic URL resolution whereby you feed the translator the contents of the .qm files on demand, or you can compile them all into a .qrc file and position them in your resource tree. That last is what we did with the app-specific translations, so I mimicked it for Qt's, filtering the total set of .qm files for the modules we use and for the locales in our tier-one localization target languages. This involved a complicated python script, and a few extra lines of Cmake, including one very elusive one (QINIT_RESOURCES) that gated everything until I realized it was needed for this platform. I'm only wrapping this up, so if anyone else is confused enough to find this question, that there are some general comments to set things straight.
django-registration is missing some translations for german.
See github Search for "". Translations are were but "broken".
I don't want to fork or change localization files localy.
Is it possible to provide translation for some strings in my app/project?
You just mention the 2 methods that are candidates for the translation of a string. If you do not want to fork the project nor change the localized files then I believe there is no other way of translating it.
Last resort method: Make an identical file of django-registration that includes the to-be-translated string and add translations there.
IMO the only way is to fork the project, run ./manage.py makemessages and voila! Translations are there. Another thing you can do is to try to contribute to this package by fork it first and then make a pull request! That's the beauty of open sourcing!
I have a reasonably simple Django (1.1) site where i need some basic interface and other texts to be translated between two languages. I've created the po files using manage.py makemessages, translated them (using poedit), and compiled the mo files using manage.py compilemessages as outlined in the i18n docs for Django.
But the problem is; most strings still show up in the original language...
i checked that the po files actually contain all strings
i checked that the mo files were freshly generated after the last translation effort
the language does actually change when i switch using the getlang() method
a few strings -do- end up being translated when i switch
but most don't...
Not really sure where else to look... Is there any app that i can use to check whether the compiled mo files are valid & complete for instance? Could these strings be cached? (i'm not using any caching middleware)
Found it!! While pulling out hair trying to figure out what was causing my woes i commented out django.middleware.locale.LocaleMiddleware from my MIDDLEWARE_CLASSES and refreshed the page in an attempt to try everything. Obviously that just turned off translation all together but when i turned it back on again, all my fine translated strings were showing up as they should have been all along.
So i'm guessing something, somewhere get's compiled/cached when you turn on the locale middleware and the only way to refresh it is to turn it off and on. Restarting the server didn't help so this a bit counter intuitive, but who cares it works! :)
I'm using gettext to handle translations on a C++ project of mine. I generate the .pot file using xgettext and then I create .po files for spanish and english using msginit (en.po and es.po) .
The problem is that, although the locale on my system is set to spanish, the .po file that gets automatically filled is en.po, where it should be es.po, because all strings are by default written in spanish in my project. All in all, the content from en.po should be the one in es.po and viceversa.
Is there a way of letting xgettext and/or msginit that spanish is the default language?
Using other languages than English as the base language of your project has been considered a recipe for trouble for a long time. This is no longer true today.
With msginit 0.19.8.1, when you run msginit -l en -i project.pot, the file en.po gets created but all translations are initialized with their original value. Obviously msginit assumes that English is the base language of the project. But that can be easily fixed: Just open the en.po in your editor and throw away all entries but the first one (the PO header).
When invoking xgettext you should always give it the option --from-code=utf-8. Other than that there are no problems to use another base language than English.