I have my application with all the translations working perfectly except the 'OK' and 'Cancel' contained in the wxTextEntryDialog dialog. How can I get these to translate properly? Even the wxMessageBox is working fine when using OK and Cancel but wxTextEntryDialog doesn't just seem to translate to any other language.
I have used the following snippets for the languages assignment within my code:
wxLocale m_locale; // locale we'll be using (this is defined in the header file of my app)
// Within the source
lang = wxLANGUAGE_CHINESE_SIMPLIFIED; // for e.g. could be any language
m_locale.Init(lang);
// normally this wouldn't be necessary as the catalog files would be found in the default locations, but when the program is not installed the
// catalogs are in the build directory where we wouldn't find them by default
wxLocale::AddCatalogLookupPathPrefix(wxT(LanguagePath));// add path of install
// Initialize the catalogs we'll be using
m_locale.AddCatalog(_("messages")); // .mo file generated by my application language specific .mo file
Thanks in advance for any help.
Does your call to Init() succeed? You should really check for its return value, it's possible that it doesn't find wxstd.mo, which contains translations for all the messages used inside wxWidgets, because you call it before setting the lookup path. You need to
Ensure that wxstd.mo is available in your catalog path.
Call Init() after setting this path.
Check its return value.
Thanks #VZ. for the insight. Your approach helped me debug my application better i.e. I was able to see that the Init() did not succeed by checking the return value. With this I was able to investigate further. Also, the wxstd.mois just the default .po generated .mo (not translated so why would I require this?)
Solution: I had to add the wxWidgets translation files i.e. the .mo generated catalog files from the .po files contained in the <wxdir>/locale/. I had to copy them to the same directories as my messages.mo. Hence, the working code looks like this for Simplified chinese.
wxLocale m_locale; // locale we'll be using (this is defined in the header file of my app)
// Within the source
lang = wxLANGUAGE_CHINESE_SIMPLIFIED; // for e.g. could be any language
wxLocale::AddCatalogLookupPathPrefix(wxT(LanguagePath));// add path of install
m_locale.Init(lang, wxLOCALE_CONV_ENCODING);
m_locale.AddCatalog(wxT("zh_CN")); // This is the .mo file I generated from the wxWidgets .po files
// Initialize the catalogs we'll be using
m_locale.AddCatalog(_("messages")); // .mo file generated by my application language specific .mo file
I did not include the checks for a purpose because I want the application to run in english even if the language is not supported but I did use it for debugging
Related
The REDHAWK IDE insists on expanding environment variables when creating the Makefile.am.ide file. For example, assume that $SRC_ROOT is /srcpath and I add an include path in the Path and Symbols window of the C/C++ section of my project as below:
${env_var:SRC_ROOT}/include
the generated Makefile.am.ide file contains:
rehawk_INCLUDES_auto = -I/srcpath/include
when what I really want is:
rehawk_INCLUDES_auto = -I$(SRC_ROOT)/include
This is important because this file is used by other team members that have different values for $SRC_ROOT. Currently we have to put the include path in Makefile.am, but then the IDE doesn't see the header files in the directory and sees errors for the code referred to in the missing headers.
Is there anyway to get RHIDE, to not expand the environment variables when it generates Makefile.am.ide?
Not exactly what you are looking for but you can always disable the auto-updates of the Makefile.am.ide by disabling the REDHAWK C++ auto-inclusion builder. This is in the projects properties in the Builders section.
This will allow you to add to Eclipse's Paths and Symbols section without the auto-inclusion builder picking it up and adding it to your Makefile.am.ide.
If you do choose to disable this builder you will then need to manage the addition of new source files on your own.
Youssef's answer is not a bad one, but I've come up with a different way to work around the problem. In Makefile.am, override the redhawk_INCLUDES_auto value to be what I what it to be:
include $(srcdir)/Makefile.am.ide
#Override the value from Makefile.am.ide that may be wrong!
override redhawk_INCLUDES_auto = -I$(SRC_ROOT)/include
This requires one to update any custom include directories in both the IDE and the Makefile.am file, but managing the source files is still automatic.
It still has the issue that the Makefile.am.ide file's contents will be different for other developers which complicates version control. So I don't consider this be a complete answer to the problem.
I want a run a build step that looks at a .h file, adds some code based on some external params, and hands the resulting file to the preprocessor.
I see the "Custom Build Step" in the project properties. It seems to need an output file. I just want to forward the results to the preprocessor.
It seems like the custom build step wants to do a 1-time process, not per-file or by file type.
The problem is that I don't know how to send my external executable the file currently being processed (eg, "HelloWorld.cpp"). $(InputName) and %(Filename) are blank and docs say it's deprecated. How do I send the filename to my external executable?
But even if I get that working, I don't want to set this per-file. I want all header files to go through this process.
Any ideas?
I've looked at:
https://msdn.microsoft.com/en-us/library/dd293663.aspx?f=255&MSPPError=-2147217396
https://msdn.microsoft.com/en-us/library/hefydhhy(v=vs.90).aspx
https://msdn.microsoft.com/en-us/library/ff770593(v=vs.140).aspx
working on a debug, x64 config on windows.
First of all, No, you cannot modify a file and pass along the results to the next stage (that I could see). I'd need some sort of Program Transformation System.
So I need an intermediate file. That file has to be added to the project, even if it gets overwritten by your code generator. I can associate c++ header files with a custom build tool, and they will all get called one-by-one in the stage of the build specified in the Custom Build Step. The custom build tool will modify the intermediate file(s), and all is well.
The VS 2015 name for the current file being processed is %(Filename). In older versions it has been $(ProjectName) and $(InputName).
I am working on some C++ code, that mainly provides a class for two other projects that share it but also includes a small program so that it can be used from the command line if needed. The class has to load some resources, that are written to several files in a resources folder. The path to these files is of course hard coded into the program, since I don't want any client using the class having to worry about loading those resources, other than calling an init method. When I compile the project on its own, with the hardcoded fopen("resources/myresource.dat") it works as expected, but when it is included in another project, the whole thing is typically placed into a separate subdirectory with only the header included as #include "subdir/myclass.h". In this case the hardcoded paths are invalid as the working directory is one folder higher.
How can I make sure the path to the resources folder is always valid, regardless of the path of the include?
How can I make sure the path to the resources folder is always valid, regardless of the path of the include?
It's not anyhow related to the include's path.
What you actually need is an installation routine, that provides you with a environment variable like $MYAPP_RESOURCE_PATH and having that expanded instead of your hardcoded path "resources/myresource.dat".
You can retrieve the environment variable's value with the getenv() function.
If you save any webpage under Windows, you will notice it creates a folder which is "linked" to the html file, like:
(file) Twitter.htm
(folder) Twitter_files
If you try to copy either file or folder, e.g. Twitter.htm, Twitter_files will also be copied along.
Can I achieve this functionality somehow? I am asking both as a plain Windows user and pro grammatically (e.g. a C++ API). I don't see any flag in the file properties to make them linked.
I can switch languages in my Django application by changing LANGUAGE_CODE in the Settings.py file for the application.
But I'm not sure where the actual text is coming from.
In path-to-django/contrib/auth/locale/, there are directories for many languages containing the translations of the text I'm displaying. But if I move an .mo file for a particular language to a new name, I still see text for that language -- even after I restart Django. So where does the text actually come from?
Also, for the 'en' locale, the translated text is always "" (empty string). Does ugettext_lazy just return its input string in that case? If not, where does the English text come from?
It is a difference, if you speak of translation in the django admin or within your application. The path you mentioned .../contrib/auth/locale refers to translations in the django admin.
For special translation within your application you should have a locale/ folder in your project. This folder is created when you run the django special script named "django-admin.py makemessages".
The script runs over your project source tree or your application
source tree and pulls out all strings marked for translation. It
creates (or updates) a message file in the directory
locale/LANG/LC_MESSAGES. In the de example, the file will be
locale/de/LC_MESSAGES/django.po.
For detailed explanation, please look at django i18n documentation
After you have created your message files (*.po) and after you have written your own translations in the message files, don't forget to compile them:
Compiling message files
After you create your message file -- and each
time you make changes to it -- you'll need to compile it into a more
efficient form, for use by gettext. Do this with the django-admin.py
compilemessages utility.
This tool runs over all available .po files and creates .mo files,
which are binary files optimized for use by gettext. In the same
directory from which you ran django-admin.py makemessages, run
django-admin.py compilemessages like this:
django-admin.py compilemessages
That's it. Your translations are ready for use.
It turns out there was a system-wide Django installation that was being used, rather than my local installation.
By creating a locale directory within my app, I'm able to override the strings used in the system-wide installation. I just modify the .po file there, and compile it.