Is there an official list of Inno Setup messages like "WinVersionTooLowError" somewhere? I need to change the "This will install AppName on your computer" but don't know how. Thanks!
The default language file should have a complete list, you can view the online CVS version here.
The translation download page contains this note:
Starting with version 5.1.0, the Inno Setup compiler will accept a
translation even if it's missing messages (it will use the default
English messages to replace them) or contains unknown messages.
so you should be able to create a custom English language file that only changes a couple of strings if that is what you want, but it is also possible to override the strings without using language files.
You might also want to take a look at Inno Setup Easy Translator
Related
Before I run off the in wrong direction, if adding a new output format to Sphinx, might one have to add special case code to all existing Sphinx extensions?
For example I see that the 'todo' extension seems to try and use admonitions but has to have special case latex code - might I have to do similar for every extension that someone might use unless I can do some similar jiggery-pokery to reuse existing formatting features?
All extensions that make use of Sphinx's add_node() function need to be adjusted to cover the new output format. Otherwise, your new output format builder will not be able to process the custom nodes. You still should be able to build, though.
However, let me clarify the following:
Not all extensions make use of add_node().
In many cases, you should be able to register an already existing function for the new output format, just like in the example of the extension development tutorial in the Sphinx documentation.
You should be able to override the add_node() registrations of the extensions you use without modifying the source code of the extensions by re-registering the nodes at the end of your project's conf.py file.
I want to change the language of the app inside it. I want to allow the user to change the language from settings.
Is it possible?? because I can't find a setLocale() method or something similar.
Thanks.
I'm afraid this isn't possible using the build in tools. The build in tools are used by Android and iOS specifically to change the language based on the OS settings.
The way you can do this is by making it custom. Defining your own global function to get translations from (instead of the L() function). But this also requires you to put your translation files somewhere else.
The following line works although it is not documented. I think it will be documented soon and you will get a convenient way to change language on run time. Of course you will have define your own translation.
Ti.Locale.setLanguage("fr");
It is possible. I am using this module from the marketplace:
iOS: https://marketplace.appcelerator.com/apps/144434#!overview
Android: https://marketplace.appcelerator.com/apps/144430#!overview
I'm trying to get some custom info to be seen in the file->properties view of our NSIS installers, mostly who built what when a developer is building an installer on his/her own machine. (For testing, etc)
I thought PrivateBuild and Comments would suit nicely, but they don't show up when viewing File Properties -> Details.
According to this answer by Rong-Chun Zhang (scroll down a bit) these properties aren't shown any more. The workaround is to implement a shell extension, but that seems to be over the top for just some text strings that we need to track.
Adding mercurial rev-hash and build user/computer to versions or description makes the string too long, and line-breaks don't work properly. :(
Any good workarounds?
I guess you just have to accept the fact that Vista/7 are dumbed down compared to XP.
It is possible to check the command line for arguments in NSIS, so perhaps you could add support for a /dumpversion parameter and just open a MessageBox and quit in .onInit
I am converting some docs to pdf using wkhtmltopdf (currently using perl and the command line versions). Is it possible to change the "PDF Producer", "PDF Version" and "Fast Web View" fields? The current defaults are "wkhtmltopdf", "1.4 (Acrobat 5.x)", and "No", respectively. I didn't see anything in the wiki page
Pass the following with the command line to see supported features: " --extended-help"
Not sure if those specific params are supported or not.
I patched wkhtmltopdf to support an additional flag recently, and it would be quite easy to add parameters to change those. I don't believe they are supported currently, though.
PDF Producer: Nope. Most apps want folks to know that particular app generated the PDF.
PDF Version: Nope, but trivial. The version number at the beginning of the file is just a courtesy really. What exactly are you after with this? Chances are you don't really need it. The PDF generated isn't going to acquire any features automagically just because the PDF claims to be this version or that. It's only really used so a viewer opening a newer PDF can say something like "I don't support this version, some stuff might not work". Because everything will work regardless (unless someone happens to have a VERY old version of Acrobat/Reader), I don't see the issue.
Fast Web View: Nope, and decidedly non-trivial. "Fast Web View" means everything needed to display the first page of the PDF is sorted to the front of the file, and there are various "hints" on where an app downloading the PDF can find this or that. It's not just a flag, not by a long stretch.
Zero for three. Sorry.
I've created an OS X installer package that includes localized resources (License.html, Readme.html, etc.) In particular, it includes a localized postflight script, since some of the post-install actions differ from language to language; opening a per-language file after the install completes, for example. The package is created as part of an automated build, not through Package Maker.
Originally I used the 'full' locale name as the localized Resource folder name; for example, English.lproj. Everything worked fine. Recently, I switched to the ISO name, i.e. en.lproj, since I discovered that was what Package Maker was using, and this question indicates that form is preferred. Everything worked exactly the same, except that the postflight script is no longer executed.
I did some more testing, and noticed that, even when it works (using the full language name as the name of the folder), it logs this message to the console:
Localized installer script postflight found in the <name> package. Using compatibility mode.
I can find barely any mention of Installer localization in Apple's developer docs, much less anything specific about scripts. Does anyone have experience with this? Is it a bug for it not to work with en.lproj, or was it a bug for it to have worked before?
Things that I don't understand:
If you're not creating these packages with PackageMaker, what are you creating them with?
Why would a postflight script ever need to be localized when conditional logic would almost surely suffice?
It turns out that, no, this is not supported anymore.