Localizing with ICU recommends keeping localizable data in XLIFF format.
So I used GNU xgettext to extract strings to gettext format files, and then converted them to XLIFF files with po2xliff.
Finally I tried to use XLIFF To ICU ResourceBundle Format Converter to turn them into ICU resource format, before I found it not work. It complains the error:
The XLIFF document is invalid, please check it first:
Line 2, Column 68
Error: cvc-elt.1: Cannot find the declaration of element 'xliff'.
Almost the same error was reported years ago and is yet to be fixed.
Line 2 of the poor XLIFF file was:
<xliff xmlns="urn:oasis:names:tc:xliff:document:1.1" version="1.1">
Well, I edited the line in accordiance with example.xlf in Localizing with ICU page (there are lots of typos in example file), retried, and ended up with:
ERROR: java.lang.NullPointerException
So what's the best practice of localizing with ICU4C and XLIFF?
Considering that the XLIFF To ICU ResourceBundle Format Converter does not yet support XLIFF 1.2 (which has been around for many years) I would recommend to stay away from XLIFF and to use po files for localization. There are several localization tools that support po files: in the answers to this question and this one you will find a fairly large number of localization tools that handle po files, and new ones are still being developped (like this one).
Of course not every translator will be able or willing to handle po files, but the chances of getting your software localized are much better via po than by trying to go the XLIFF way.
I can't answer your question on the best practice for localizing with ICU4C and XLIFF, but I have seen the "The XLIFF document is invalid" error when I used the wrong version of the Java JDK while building the ICU resource.
On my system, I see the error when I use jdk1.7.0_67. Everything works fine if I use jdk1.6.0_45. This is with ICU 52.1. You might need to verify that you are using the correct JDK for the version of ICU you are using.
Related
I am looking for an executable (or a library that I might embed in C# or via Managed C++ into the C# project) to create binary diff files for two folders and their contents and a patch tool to apply those patch files as well targeting Windows.
This SO post refers to various tools such as bsdiff/bspatch which is highly dated. The 3rd party executable that is available here does not work when trying it out though. Another variant that is not compatible with the original is the following. Unfortunately it relies on bzlib and certain Linux headers and I wasn't really able to set it up accordingly under Visual Studio.
Anyways, all tools and posts are about 8-10 years old and I'd like to know which tools and libraries are currently maintained that I might take a look at.
I have been experimenting with Octodiff and I am impressed and will most likely be using it in production.
My project is written in C++/CX on VS2015 and I am seeking a way to generate API documentation.
After googling and stackoverflow, I have tried doxygen, VSDocman,NDoc, Atomineer Pro Documentation and SandCastle, I found these tools do not support C++/CX syntax, therefore, they cannot generate correct document.
I also tried to generate XML file which VS supports. But it's hard to read XML file.
How do I generate API documentation from C++/CX? Thanks for any suggestion
There are a lot of misconceptions about the C++/CX language extension. You tried too many products that have no hope of getting you anywhere. First and foremost is that it is a native C++ extension and does not generate a .NET compatible assembly. So knock out any that try to use Reflection to parse metadata. Out goes NDoc, VSDocman, Sandcastle. Atomineer is out, it is just an editor add-in.
So all you got left is doxygen.
Sure, it doesn't know about C++/CX out of the box. The FAQ points out that in order to make it compatible with a language, you need to modify src/scanner.l
Having a look at it, I see it already supports the C++/CLI extension. That's another C++ language extension that supports generating MSIL. C++/CX syntax is very close to C++/CLI. Just some minor differences, like the gcnew keyword is too misleading and replaced by ref new. But that's not the kind of syntax that doxygen cares about, it just wants to know about declarations. Those keywords are the same.
So the only obstacle I can guess at is that you just forgot to tell it about the language. It can't guess at it correctly from just the filename extension, .cpp and .h will get it to parse plain C++. Modify or add this line in the config file:
CPP_CLI_SUPPORT = YES
And tweak scanner.l if necessary.
I discovered that all the Swift libraries (libswiftCore.dylib, libswiftCoreGraphics.dylib,...) exist twice in the IPA. After decompressing the IPA, there is one version of theses libraries inside the folder SwiftSupport and the same files again inside Payload/Frameworks.
As far as I found out, the SwiftSupport folder is always generted by Xcode when a Swift-project is built. But where do the Swift libraries in Payload/Frameworks come from and how can I get rid of them?
I think that if your code already uses Swift, you have no set the Flag "Embedded Content contains Swift code" in Build Options to NO, otherwise Xcode will add the libraries because it thinks that you use some frameworks that have swift code
I am experiencing the same issue. I have read some answers which suggest that it isn't a big deal and I have to say that it looks like it isn't.
My app contains 3 targets - main app and 2 today extensions. When I create an archive its size is a whooping 126 MB. Most of it is Swift support libraries which are about 45 MB in my case and they are included twice.
However, when I check the binary size through test flight it is 23.6 MB. Now, this is still a lot considering that my application is a simple utility.
However, it is not too much if you take into account that Swift libraries have to be included. So far I would say that even though these libraries are included twice in the IPA they are not included twice in the actual binary.
This obviously doesn't answer the original question and I am also eagerly waiting for someone to come up with the exact solution, but it might be helpful.
I've found that playing around with 'Embedded content contains Swift' value yielded some good results, and was actually crucial for my app with an Apple Watch extension to pass validation.
I have written an answer about the details for the Apple Watch fix here.
I have received a BigTiff file with scientific data which can't be read properly with ImageJ/Fiji. There seems to be a problem with LibTiff and the StripOffsets tag.
The only options I found are using LibTiff directly (probably bad, if I'm not sure if the issue is caused by LibTiff itself) and ImageJ/Fiji.
Is there a way to have a "higher level" access (i. e. no hex editor) on the provided data?
E. g. some library or tool to "debug" the file and change properties on the fly?
I had the same problem and in my case when the files were too big for the viewers they sent this message of problems with the StripOffsets tag. Now I use my IIPImage viewer, that I builded with libtiff 4.0.3 (with BigTIFF support), to view my file, but I still am in search for a good viewer for huge TIFF files.
This is the FindGTK.cmake:
# don't even bother under WIN32
IF(UNIX)
...
ENDIF(UNIX)
So it's not intended to work in windows at all,even though I've already installed the gtk+-bundle_2.20.0-20100406_win32 days ago.
How should I properly use gtk with cmake now?
Given that you are using GTK 2.20.0 (i.e. version is >= 2), you should be using GTK2 instead of GTK. But, if FindGTK2 has the same problem, then you can use find_path to locate the header files, and you can use find_library to locate the associated library files. Putting those together, you can construct the symbols GTK2_FOUND, GTK2_LIBRARIES, and GTK2_INCLUDE_DIRS that it should produce. You may find my FindUnitTestPlusPlus.cmake file a little bit helpful; it makes use of "FindPackageHandleStandardArgs", which takes care of the nitty gritty details of making sure to fail if the library isn't there and the REQUIRED flag is given. Unfortunately, there really isn't much documentation out there on creating custom FindXYZ.cmake modules; however, you should be able to hack something together from the existing modules, I think.
Another option is to contact the maintainer of that particular module. A list of CMake find module maintainers may be found at the link. Philip Lowman is the go-to guy for the FindGTK2 module.