When using the Twitter API you get emojis as unicode characters. You can then easily parse out and display emojis as pictures. One example of such a parsing tool is Twemoji, which is the official emoji parsing tool from Twitter. In the twemoji.js file there is a long regular expression they use to parse out the emojis.
However, this file has not been updated in two years, and there are many emojis missing from Twemoji that are displayed just fine on twitter.com.
Does anybody know of any other well maintained list of current emojis supported by twitter.com? A bonus would be that they use/provide a regular expression I can import into my own code.
Twemoji has a somewhat weird structure on Github due to a CDN mirroring, which means that when Twemoji releases a new version, or updates the regular expression in newer versions, the original versions will still be there.
The twemoji.js file on the front page is indeed an old version. However, they have released newer versions, so on the root of the project there is currently a folder named 2. This file contains a twemoji.js that is much newer than the one at the root level. The regex in this file catches all emojis currently displayed on twitter.com.
So when getting a new regex for your app, remember to not check the root folder, but look for a numerical folder which contain newer versions.
Related
Of course I added the relevant Spanish files and I initialized it like this: G8Tesseract(language: "spa"); but it just keeps giving me the same error (which isn't even very clear). In English it works just fine, by the way; it's probably an issue with the data files, but I couldn't find more of them. Any ideas or something?:(
You are using the wrong data file. Tesseract for iOS doesn't support Tesseract's last version. You must look for the TESSERDATA files for version 3.02. If you use newer files you get that error.
Take the files for Tesseract ver. 3.02 from here: tesserdata files. At the bottom of the page you'll find the files to download.
Test it in Tesseract-only mode. CUBE doesn't always work with non English languages.
I am generating an iOS app via some tools. No need to concern about them, I have to do things that way.
Localization
The app is generated just fine, however I need to have the app be available for a certain set of languages. My app is actually a cross-platform app, and i am handling translation at JavaScript level. So my app actually picks the proper strings.
I just need to have my app be recognized in the Store as supporting those languages
Manual approach
I used to handle this by automatically generating language folders in Resources. So my automation scripts, would basically take the list of supported languages (say it, en and fr) and generate the following folders and files in my project:
MyApp
|
+-MyApp-Info.plist
+-Resources
|
+-en_US
|
+-Localizable.strings
+-it_IT
|
+-Localizable.strings
+-fr_FR
|
+-Localizable.strings
And Localizable.strings is just a placeholder file with a C-style comment in it.
Not working anymore
This did the trick so far, but now it is not really working anymore. The store recognizes my app to be only an English app, it does not list French and Italian anymore.
I am targeting iOS 8.0+ and developing on latest version of XCode.
How can I fix this?
Try renaming the localization folders so they have the ".lproj" suffix. Use the naming scheme as defined in the Apple Internationalization and Localization Guide under Managing Strings Files Yourself.
I would also add at least one string resource in the Localizable.strings file for at least one of the languages. At least one localized string resource may be needed to flip the bits and mark the app as supporting the additional languages.
As the title states does iOS support PDF/A?
I tried to open it, but mostly I get a white page with errors like
illegal character `/' encountered in hex string.
illegal character `/' encountered in hex string.
invalid stream length 557; should be 563.
FlateDecode: decoding error: invalid distance too far back.
FlateDecode: decoding error: invalid distance too far back.
invalid stream length 51645; should be 52016.
FlateDecode: decoding error: invalid bit length repeat.
FlateDecode: decoding error: invalid distance too far back.
FlateDecode: decoding error: invalid distance too far back.
Perhaps I'm doing something wrong, but I didn't found any information which types of PDF the UIWebView or QLPreviewController support.
Edit:
Now I created a Word 2007 document with a single text line and saved it as normal PDF (with Adobe Plugin). Then I openend the PDF and converted it to the different available standards with the Preflight tool:
PDF/A-1a
PDF/A-1b
PDF/A-2a
PDF/A-2b
PDF/A-2u
I also checked if it is really supporting this standard with the Preflight tool. Then I displayed the PDF/A on my UIWebView and the text got displayed and I didn't get an error in the console.
Then I got it managed to get access to the problematic PDF and I also checked it with the Preflight tool. The summary for PDF/A-1a and PDF/A-1b was:
File header is not compatible with PDF/A
Syntax problem: PDF file contains data after end of file
It doesn't meet any of the standards available in the Preflight tool. So yes iOS does support PDF/A, but you have to check if your PDF is valid.
The short answer to your question is: yes.
The longer one is, well... a bit longer :)
PDF/A, or PDF for Archival is an ISO standard that is based on the ISO standard for PDF itself (ISO 32.000). As a consequence, any software that supports "PDF" must also necessarily support PDF/A. Or otherwise stated, all PDF/A files are PDF files, but not all PDF files are PDF/A files.
To complicate matters though... there are many different versions of PDF out there, and there are at least 8 different forms (parts and flavours together) of PDF/A. Not all software supports all versions of PDF, more advanced features (such as JPEG-2000 compression to name but one example) might not be supported by your particular platform or software of choice.
So you have two steps to go through:
1) Make sure your PDF/A is valid - there is commercial software to do this such as Adobe Acrobat or callas pdfToolbox or pdfaPilot (caution: I'm affiliated with these applications) and there is free software to do this (have a look here: http://www.pdf-tools.com/pdf/validate-pdfa-online.aspx for example).
2) If your PDF/A is valid, make sure that your software / platform supports the features in that particular PDF/A file you are looking at. PDF/A-1 for example is an older standard than PDF/A-3 and supports less features. Hence you'll have a greater chance that a PDF/A-1 file is supported than a PDF/A-3 file.
I have read a few tutorials about iOS's tools and processes for i18n/l10n, and am unpleasantly surprised with what I'm seeing. It seems there isn't a solid way of externalizing user-facing strings out of objective C files. Am I missing something?
Description of the problem:
There is a tendency to place English strings directly into the .m file, and the Apple documentation seems to encourage this. While this is also possible in Android, as least in Android there is a clear distinction between externalized and non-externalized strings. With iOS, on the other hand, code that calls for a string tends to look like this:
NSLocalizedString(#"There was an error loading the image.", nil)
In this case, "There was an error loading the image." is the key for this string resource. Therefore if I want to make another reference to the same string in some other place we have to again write code like this:
NSLocalizedString(#"There was an error loading the image.", nil)
But now I have to make sure that I spelled these two strings the same and there is no compile time check to help me confirm that. I could write a helper function called createErrorString, but that's not fun. And I could replace "There was an error loading the image." with a more sensible key like "ERROR_IMAGE_LOAD", but that does not seem to be a common practice, and Apple seems to discourage this sensible behavior. Here is what their documentation states:
"A common convention when developing applications is to use a key name
that equals the value in the language used to develop the
application."
It looks like Apple is recommending that you put the full English string in your source code. So I'll have to try to convince my colleagues to go against Apple's guidance.
Now that I've got all of these user-facing English strings (or keys) in the source code, Apple includes a tool called genstrings that parses the .m files, and spits out a Localizable.strings file that I can then send out for translation. This might work if you are only going to get your app localized one time, but in our company localization is an ongoing iterative process. Look at what the Apple documentation recommends:
"For subsequent runs, it is a good idea to save a copy of your current
strings files before running genstrings. You can then diff the new and
old versions to determine which strings were added to (or changed in)
your project. You can then use this information to update any already
localized versions of your strings files, rather than replacing those
files and localizing them again."
That doesn't seem very good. In Android and Windows8, you internationalize your source tree one time, and from that moment on your externalized strings are owned in the xml files where they belong; in iOS they are owned in source code (sort of) and then tabulated into some intermediate file (or is it?) by some crazy tool. Is the Localizable.strings file an intermediate file or should it be committed into git - we are still debating this at my company.
(And from what I can tell, this is only the beginning. In xib-land, which is where 90% of your user-facing strings live, there also seems to be an inefficient mechanism for l10n. Wil Shipley's article describes this at length.)
Does anyone have any suggestions on a good way to externalize strings in iOS? My main question concerns objective-C strings, but answers pertaining to xib files would also be much appreciated. Thanks!
I found the recommendation to name the key like the english string strange, too.
I name the keys, value e.g "Menu1SettingsTitle" = "Settings".
I dont need genstrings tool, just externalize manually.
And no, the string files is not an intermediate step, they should be in git.
However with that approach i noticed three drawbacks:
1) I detected duplicate names, but that can be moved to a common section for strings like "cancel, delete"
2) If you forget to put a string into that language file, it cannot be found and then the key is displayed, which looks very strange, of course. Otherwise with apples reccomendation, If the key is the english word, it looks "only english" but not worse.
3) The translation process is easier if english is always left, instead of "Menu1SettingsTitle". to solve that i put a comment above, but dont know if the translation service would be happy with that.
After a couple of hours searching I decided to use two different approaches: one for the storyboards and one for the text inside the .m files. The result are two files Localizable.strings for the Objective C text and the internationalized storyboard.
The update_storyboard_strings.sh can automatically extract translatable strings from storyboards and update strings files. The source code (by mikezang) can be found at:
http://forums.macrumors.com/showpost.php?p=16060008&postcount=4
For the objective C NLS I use another script around the xcode-tools by Frédéric Sagnes:
https://github.com/ndfred/xcode-tools
I had to call it for each language in order to get the desired results:
python scripts/xcode-tools/update_strings.py --import=MyProject/Base.lproj/Localizable.strings MyProject/Base.lproj/Localizable.strings
python scripts/xcode-tools/update_strings.py --import=MyProject/de.lproj/Localizable.strings MyProject/de.lproj/Localizable.strings
Now put both in one script and add it to your Xcode project as a last build phase.
I just realized that Bundle Creator OS Type code in my iOS app's Info.plist value is ????? in Xcode 4. What is the value supposed to be?
It's used to identify your application. You don't have to change it for an iPhone application.
Take a look at these links:
Information Property List Key Reference
Mac Creator and File Type Codes
Data Type Registration
It's not really used anymore.
It's a holdover from the Classic Mac OS days
when it was a datapoint used mainly to determine what apps could create or edit or read file types.
Back then you had to register them with Apple.
I don't think they even provide that service any more.
OS X and some apps might still use it in rare cases under the hood but its very legacy.
As you can imagine, the severely limited possible permutations made it untenable long term.
UTIs are the preferred approach now. The system then uses a combination of these and file extensions and magic numbers. Though on ios that may not be true as much as OSX.
It is just the four letter code to identify the bunder creator... for example for apple it is APPL...
It can be ???? or if your app name is "myApp" you can give "MYAP"... If you have many apps you can give first 2 characters with your app name and next 2 characters with company name...
For example apple uses CF for core foundation, AV etc
http://developer.apple.com/library/ios/#documentation/general/Reference/InfoPlistKeyReference/Articles/CoreFoundationKeys.html
Just to give the historical perspective on extensions and file type and creator codes.
File extensions were part of the file system in CP/M and were intended to function something like what file types and creator codes actually did in MacOS. At the time, it was expected that each application would use a unique extension and only the one application would ever edit its own files. In the file system, the file name and extension were stored in two different areas, so the extension was not part of the name. Remember, at that time most systems had only a few applications, and file contents were specific to an application. They were never intended to be visible to end users, but due to an error in the directory command in CP/M, they were shown displayed as if they were part of the file name. MS-DOS picked up the convention, and the rest, unfortunately is history.
Apple's initial file system design saw the shortcomings of the extension concept, the primary one being that some file types were likely to be used by more than one application and with standardization of file formats, having more than one application that could operate on a file would be common. Therefore Apple split the file creator - the app that created the file - from the file type. By default if a file was double clicked, the originally creating application would open it. However, if a user did a file open from within an application, then all compatible files were supposed to be listed, even if that app was not the creator. Also, it would be possible to list all the applications that could open a file. Semantically, as intended in CP/M, the type and creator codes were separate from the file name itself.
Developers that properly registered their applications with Apple got their own creator codes. The problems with this concept came about from two sources: 1. Developers that hijacked other's or Apples own creator codes. 2. Unix systems, which never had a formal filename extension (all file names were a single string) began adopting the convention to end the file name with a dot and some additional letters to indicate file type. In the Unix convention, the extension is part of the file name itself, unlike CP/M and MS-DOS.