We are using QT 5.5 successfully throughout our VC++ projects in VS2015.
Now, i am adding i18n thereto, using QTs Linguist tools to create my strings 2b translated and the resulting .qm files. I load the files through QTranslator object, the translation itself seems to work, but they get displayed wrongly.
As german is my mother tongue, I have to type several umlauts, beside any other special unicode-characters I definitely want to support.
As en example, I use linguist to translate over to über, and the resulting text in my application reads über. What I can surely recognize as an encoding mismatch.
I already had a look on the i18n example, which displays correctly for all of the provided languages, so I right now do not know what's wrong after I checked all file encodings.
Anyone any ideas? Or even has the same problems? Or had them but solved? Any suggestions were greatly appreciated!
This seems to be a Windows-specific problem.
Instead of using QString.toStdString() (what breaks the correct string), better use QString.toLatin1() at least for the languages to support yet.
Related
I'm thinking about using the internationalization support for Chrome extensions as described here.
The suggested way to make translations is to first create the English messages.json file, then copy it over and translate it into the given language.
My problem is that this works all right for the initial translation, but when there are already some translations and some changes happen in the extension I don't see an easy way to update the translations.
I guess I would need tools for these tasks:
detect new untranslated strings
detect strings changed in English that might need revision in other languages too
detect strings not used anymore
I guess by keeping around the original English messages.json file and using diff tools I could do this by hand, but I was wondering if there are any tools that can help with this.
You can try https://webtranslateit.com/.
We are using it.
I'm a newbie to SugarCRM development. In my project, I have to generate a pdf for one entity details(say Account details). On details page, I have added "Print PDF" button, upon clicking this button I have one independent script (I mean to say that it was not implemented as per Sugar framework). In this script we are querying database for the required details and building one html string. Using html2pdf library, converting this html string to pdf.
I dont know whether it is an efficient implementation or not, but everything is working fine as per the requirement. But we have one problem when the original string contains some special characters like currency symbols of different countries. We are getting the html fine, but in pdf getting question marks (?) for those special characters.
While trying to fix this issue, when I looked into SugarCRM code, I found some pdf classed inside includes/ directory that creating an impression that Sugar itself has some built-in library to generate pdf's. Is it true?
If that is true, will it solve my problem, i.e. displaying different countries currency symbols in pdf.
Can anybody please help me to in resolving this. Thanks in advance.
-Venkat Nehatha
Venkat, SugarCRM does indeed have its own pdf generation ability. We use it to generate customer orders, quotes, invoices, and statements.
Though I've done some work on the pdf generation myself, I don't think I'm really experienced enough to be able to guide someone else in detail in the use of Sugar's pdf capabilities. I can tell you that we use pdf generation only in our own custom modules, so the files are found in [sugarRoot]/modules/[customModule]/. (You may know that unless you know exactly what you're doing, NEVER modify the main SugarCRM files in the [root]/modules/ folder!) In the previously mentioned custom module folder are two sub-folders, "sugarpdf", which has the code that accesses the modules/database to get the information to write to the pdf, and a "tpls" folder that holds the layout information for the header, body, and footer of the pdf, in HTML format, using the information from the sugarpdf folder's file.
I strongly recommend you visit the SugarCRM developer forums where you will be in touch with many developers much more experienced than me in Sugar.
I hope this helps in some way.
When I try to compile the example from the front page of the go language website with the 6g compiler, I get this error:
hello.go:5: syntax error near "<string>"
I search on Google reveals that a few people have experienced this, but I have found no solution. The answer always seems to be: "It's works for me, you must do something wrong".
I've found a description of the problem that dates back 5 months, so I suspect it's not a problem with the particular build of go that I'm using. Besides, I've tried pulling a newer version, and the problem persists.
The source code in question:
package main
import "fmt"
func main() {
fmt.Println("Hello, 世界")
}
Btw, I'm saving the source code as UTF-8 with LFs for newlines. It shouldn't be a text encoding issue. I've also tried with different strings not containing "exotic" characters
Try "which 6g".
You might be picking up an old build.
At least that was my case. I had an old 2009 build in my path.
After fixing the environment it worked.
Your special characters in there might cause conflicts with the compiler. Try to save this code in multiple ways using notepad (ANSI, UTF-8), and see whether the compiler will take any of them.
Problems like this are typical when there's an encoding issue.
If you're on Windows, an editor like Notepad++ can convert between many encoding formats, so I'd suggest converting your source to UTF-8 without BOM and then recompile.
If you're on Linux, there's a guide available showing you how to determine and change a document's encoding.
I am new to Mac OS X programming and so I am going through an introductory text that includes building interfaces using Interface Builder (3.2.3) for both Cocoa and Carbon. Unfortunately I am having problems getting some of the examples I type in to run error free in the Cocoa and Carbon simulators. So I tried downloading the source code files from the publisher's website and found that they ran with no problems.
I'm trying to find the differences between the publisher's working and my non-working versions of the code. I started by just trying to compare the attribute settings as listed in Inspector but I could not find any differences. I then came across File Merge which I used to compare the .nib files for the two different versions. File Merge does show the differences but since I am unfamiliar with the markup language used in the .nib file and it lists too many differences to track down without being knowledgeable enough to know what is relevant or not, it really hasn't been very helpful.
My question is whether or not there is a tool or method available that will better show me the differences in the two versions of the code than what I can see in the Inspector window but also shows it in a more condensed and user friendly form than what is provided by File Merge. What is the recommended tool/methodology to debugging code in Interface Builder?
Also, can anyone recommend documentation where I can become familiar with reading and debugging the code in the .nib file in case that is the only way to find the differences?
Thanks
Check out nib2objc
Convert both yours and the example nibs to code.
It will convert nib files to what looks more like Obj-C code. Then just diff sections of them and see what's different. Should be pretty easy to read code vs NIB files.
The command line program ibtool can convert a nib into a text format, but I don't know if that will be sufficiently readable.
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.