I'm trying to localize my Core Data model in order to display better error messages. I followed the instructions on http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CoreData/Articles/cdUsingMOM.html without success.
My model file is v8.xcdatamodel, so my strings file is v8Model.string. I want to have the property "name" displayed as "Name". So I added the line
"Property/name" = "Name";
to the strings file. But it just does nothing when an error message is displayed. Any ideas what I missed?
thanks,
Martin
Your strings file should be v8Model.strings, but maybe that's just a typo in your question. Notice also that .strings files must be saved in UTF-16 encoding, as documented here.
The .strings file should be saved in the appropriate localization folder, such as en.lproj.
Related
My goal is to extract the localization keys and strings from a Base.lproj's .nib files.
While most compiled nib files use the binary plist format, I ran into a few that are in a different format, where the file starts with "NIBArchive".
An example (in macOS Monterey) is the file at:
/System/Library/CoreServices/Finder.app/Contents/Resources/Base.lproj/ClipWindow.nib
For "bplist" files, I can easily read them via CFPropertyListCreateFrom… into a NSDictionary, and then find the translatable strings therein (inside the "$classes" entry they're always three consecurity dict, string and string entries, with the dict containing the keys "NS.string", "NSKey" and "NSDev", and the following strings being the key and value of a translation entry, similar to what .strings files contain).
The NIBArchive, however format doesn't seem to be documented anyway. Has anyone figured out how to decode the entries in a meaningful manner so that I could find the translation items in them? Or convert them into the bplist format?
Note that this kind of file is a compiled nib, and ibtool won't work because it gives the error: "Interface Builder cannot open compiled nibs".
I am working with random .nib files, for which I don't know the implementation specifics. All I want is to extract are the .strings contents that were originally compiled into the Base localization file.
I had googled for this format before but found nothing. Now, with a slightly modified search, I ran into some answers.
My best hope to solving this so far is this format description, determined through reverse-engineering:
https://github.com/matsmattsson/nibsqueeze/blob/master/NibArchive.md
I can build a parser based on this, but still wonder if there are easier ways.
Another possible solution is to use NSKeyedUnarchiver to decode the data, after loading it into a NSNib object, as suggested here:
https://stackoverflow.com/a/4205296/43615
This method of decoding keyed archives of unknown types is also shown in the PlistExplorer project:
https://github.com/karstenBriksoft/PlistExplorer
It seems https://github.com/kam800/MachObfuscator does include a NIBArchive-reader NibArchive+Loading written in Swift.
A user ran into an exception the other day when my code tried to parse a date from a line of text in a configuration file. The customer was using the Chinese date localization, so I figured that the issue was the parsing.
However, when reproducing the problem, I found the text in the file itself was in the Chinese format. This file is copied from a backup location, which I verified to not be in the Chinese format.
It turns out when the file was previously copied from that location by a call to IO.File.Copy(), the text changed from:
22/JUN/2016,00:00:00
to
22/6月/2016,00:00:00
The size of the file even changed.
Due to this, an exception was thrown when trying to parse that text on this call:
DateTime.ParseExact(timeString, datetimeFormat, CultureInfo.InvariantCulture)
The data doesn't have to be localized, so we always use CultureInfo.InvariantCulture. However, if the file changes the date format, this breaks.
When I copy and paste the file as usual, the file doesn't change, which is even more curious.
I verified this problem to occur on Windows 10, after changing the Regional Format to Chinese (Simplified, China).
Any ideas as to why IO.File.Copy() causes this change?
It's always good to use "TryParseExact" for parsing the datetime.
Answering your question, there might be few things you need to look into:
Look in to the code used to Copy the file.
Try using StreamReader/StreamWriter for copying the file, do specify the Encoding Type.
We're creating an app that is going to generate some text files on *nix systems with hashed filenames to avoid too-long filenames.
However, it would be nice to tag the files with some metadata that gives a better clue as to what their content is.
Hence my question. Does anyone have any experience with creating files with custom metadata in Ruby?
I've done some searching and there seem to be some (very old) gems that read metadata:
https://github.com/kig/metadata
http://oai.rubyforge.org/
I also found: system file, read write o create custom metadata or attributes extended which seems to suggest that what I need may be at the system level, but dropping down there feels dirty and scary.
Anyone know of libraries that could achieve this? How would one create custom metadata for files generated by Ruby?
A very old but interesting question with no answers!
In order for a file to contain metadata, it has to have a format that has some way (implicitly or explicitly) to describe where and how the metadata is stored.
This can be done by the format, such as having a header that says where the "main" data is stored and where the "metadata" is stored, or perhaps implicitly, such as having a length to the "main" data, and storing metadata as anything beyond the "main" data.
This can also be done by the OS/filesystem by storing information along with the files, such as permission info, modtime, user, and more comprehensive file information like "icon" as you would find with iOS/Windows.
(Note that I am using "quotes" around "main" and "metadata" because the reality is that it's all data, and needs to be stored in some way that tools can retrieve it)
A true text file does not contain any headers or any such file format, and is essentially just a continuous block of characters (disregarding how the OS may store it). This also means that it can be generally opened by any text editor, which will merely read and display all the characters it finds.
So the answer in some sense is that you can't, at least not on a true text file that is truly portable to multiple OS.
A few thoughts on how to get around this:
Use binary at the end of the text file with hope/requirements that their text editor will ignore non-ascii.
Store it in the OS metadata for the file and make it OS specific (such as storing it in the "comments" section that an OS may have for a file.
Store it in a separate file that goes "along with" the file (i.e., file.txt and file.meta) and hope that they keep the files together.
Store it in a separate file and zip the text and the meta file together and have your tool be zip aware.
Come up with a new file format that is not just text but has a text section (though then it can no longer be edited with a text editor).
Store the metadata at the end of the text file in a text format with perhaps comments or some indicator to leave the metadata alone. This is similar to the technique that the vi/vim text editor uses to embed vim commands into a file, it just puts them as comments at the beginning or end of the file.
I'm not sure there are many other ways to accomplish what you want, but perhaps one of those will work.
This is more of a curiosity than actual problem as there is an easy and propably more preferable workaround. When using Codeigniters form validation and when displaying error message the CI user guide gives two ways to set one's own validation messages: through set_message-method and editing the language file which is located in the system folder.
However when editing the language file to contain error messages in my native language (which contains special character liks 'Ä' and 'Ö') the special characters are replaced with a black diamond. When using the set_message-method from form_validation it works without a problem and the characters are encoded with UTF-8 properly.
I am wondering where lies the problem when using the file instead of the method and how to solve it?
It sounds like the file is not saved by your editor as UTF-8. Make sure that it is.
I used the instructions from here:
http://www.playframework.org/documentation/1.2.1/i18n
and created files for different languages.
I call play.i18n.Lang.change method to change the language file,
and it still takes the captions from the English file ("messages" without a suffix),
Any ideas why?
It is hard to know from your description exactly what the problem may be, so I have outlined how you should do a multi-lingual app.
There are a number of steps you must follow to get internationalisation to work. Firstly, you must change your application.conf file to declare your supported languages.
So, if you are supporting English and French, you would do
application.langs=en,fr
You must then create the language file for your French translation called messages.fr. The English language would just stay in the standard messages file. In this new file, add your name value pairs for the key and message.
The way Play processes the messages, is to look first in the locale specific message file first (so for english it would be messages.en, which does not exist, and for french it would be messages.fr). If the message cannot be found in the locale specific message file, it will look at the global message file. So your global messages file acts as the catch all.
Then, in your code, set the language for your particular user, using
Lang.change("fr"); // change language to French
Remember, that this will save a cookie for the particular user in a PLAY_LANG cookie, so check that this cookie is being created for the user.
Final note, make sure that your files are UTF8 encoded. It causes problems if it is not.
In my specific case I had
play.http.session.domain
set to something else other than localhost while testing.