Ah, you’re only testing for non .lua files.
I specifically need to find .lua files, which seem to be expunged from the list.
I specifically need to find .lua files, which seem to be expunged from the list.
Huh! So they are! Didn’t know that.
(Makes sense though otherwise anybody could read our source)
I only use GNU gettext PO files for my translations.
I had a look at the compiled iOS app bundle, and the reason the lua files are not listed is because they’re not there.
No lua files are copied over to the resource directory.
The compiled lua files are located in the resource.car file in the app bundle.
Yeah, unfortunately that does make sense given how Corona compiles (not putting lua files in those folders). But then the big question becomes how to detect those files if Corona itself can do it? If the files are actually in resource.car, I guess system.pathForFile is really just rooting through there…unless it’s a different structure between platform packages?
If there’s no valid solution I guess my only options are all of the pointless code variety:
- Write a complete table of localization codes and brute-force attempt to require-in each one
- Manually include localization files (lesson learned: never autodetect…)
(As an aside, .po seems interesting. If there was an existing multibyte conversion library I would consider it, but for now that’s just a huge amount of research and work for what could be handled by a one line require().)
system.pathForFile() operates on an OS level, and knows nothing about resource.car (except that it’s a file).
The great thing about po files is that you can send them off to translators (who know how to use poedit for translation).
When you get them back it’s just a matter of copying them into the project and it’s done.
Choosing language is a matter of parsing the po file and dynamically creating a string table.
I’m not sure why you’d need a multibyte conversion library as all strings are in UTF8.
A call to a display object would be something like:
local t = display.newText { text = tr("some-tag"), font = native.systemFont, fontSize = 12 }
tr() is a function that searches the string table for “some-tag” and returns the localized result.
Yeah, but presumably something in Corona’s execution system knows where the Lua files are, else require() would have significant problems in working. I guess I’ll have to wait and hear what Rob has to say on this one.
Anyway, for po, just seems like a lot of extra work for nothing. I have virtually the same setup except that it’s (a) already in Lua and (b) it doesn’t require writing a complex (sorry, that’s gsub) library to reinterpret everything into what it is already. Plus, using .po means dropping all of my localization-specific extensions (custom fonts, coloring, control codes, etc.) You’re right that po-edit is definitely translator friendly, though. If somebody throws up a translator I may give it a look in the future.
Well on Android, people always want to get a list of files from their resource folder, but because on that OS the .apk file is just a zip file (doesn’t get unpacked like iOS does it’s app bundles), using LFS and such to try and read system.ResourceDirectory doesn’t work. Since the resource folder is a read only resource, you know exactly what files you have in there and you can have a table or a list in your code that know’s whats there.
Its not an elegant solution, but it works.
Rob
Just for the heck of it, I opened resource.car and did some string matching.
(This works only on iOS though for the reasons Rob mentioned above)
local lfs = require("lfs") local path = system.pathForFile("resource.car", system.ResourceDirectory) if (path) then local fileHandle = io.open(path, "r"); local fileContents = fileHandle:read("\*a"); for langFile in string.gmatch(fileContents, "(/localization/%w+%.lua)") do print(langFile); end io.close(fileHandle); endSo Rob, I guess this was unclear from the docs, but system.pathForFile just flat out doesn’t work on Android if looking at the ResourceDirectory? Or is it just not seeing certain file types?
On one hand it sounds like I could keep auto-finding if I switched file formats, but I gather what you’re saying is that auto-finding just won’t work if I want to stay cross-platform.
When you us system.pathForFile on Android we extract out certain file types and make them available for the API’s to get access too. We don’t unpack the entire bundle and subfolders are included with that. Like iOS, the lua files are compiled into byte code and probably stored away in some Android resource folder.