I have tried to understand how to manage and translate Orchard PO files as described in:
http://weblogs.asp.net/bleroy/archive/2011/01/13/creating-and-maintaining-orchard-translations.aspx
The problem started when I have tried to use some Editors that I found in internet and I noticed that:
orchard translation files produced by Vandelay.TranslationManager may be invalid
edited files in external editor may broke PO translated files and prevent to use sync (valid keys are marked as obsolete and new one are added as untranslated)
First things first I tried to get a reliable explanation of PO file format, and I found here: http://pology.nedohodnik.net/doc/user/en_US/ch-poformat.html
Summary of specs:
A message in the PO file is uniquely identified by its msgid string
When same msgid is used in different files an optional context can be
used to distinguish between same msgid
After digging a bit in Vandelay.TranslationManager and all translated files I think I have found the problem.
Vandelay.TranslationManager assumes as unique Key a combination of two values:
- #| msgid (used as translation key)
- msgctxt (the optional context, that in Orchard is always defined)
The problem is that Vandelay.TranslationManager uses as unique key "#| msgid" instead of "msgid"
"#| msgid" is used in fuzzy strings and states previous untranslated string, in orchard is used as an extra information that seems more a "#. "
example of extracted PO file:
#: ~/Modules/nwazet.commerce/Module.txt
#| msgid "Nwazet.Commerce.Category"
msgctxt ~/Modules/nwazet.commerce/Module.txt
msgid "Commerce"
msgstr "Commerce"
#: ~/Modules/nwazet.commerce/Module.txt
#| msgid "Nwazet.Bundles.Category"
msgctxt ~/Modules/nwazet.commerce/Module.txt
msgid "Commerce"
msgstr "Commerce"
note that even if the "#| msgid" are different the two entries above are indeed duplicates according specifications.
Now the question:
Is that just a bug or a precise design?
Afaik Vandelay.TranslationManager is the recommended way to deal with Po files in Orchard.
Any other have problems in using this feature?
Thanks
The recommended way to deal with Orchard po files is the online translation tool: http://orchardproject.net/localize
Related
I have the following problem. I want to rebrand the Chromium label to my own brand. I have tried this:
How to change Chromium browser logo and name?
so I have tried to replace all occurrences of "Chromium" or "Chrome" in the following files.
src/chrome/app/theme/chromium/BRANDING
src/chrome/app/generated_resources.grd
src/chrome/app/chromium_strings.grd
Now I need the browser to be in another language than English. Compiling the browser, some sections of the UI now have my new brand, but are still written in English, i.e. not translated. I suppose the reason is somewhere, that I have modified the .grd files as these are the template files for the translation. I have also looked into the associated .xtb files. There are the unique numerical ids for the translated string, and I think because I altered the occurences to my own brand in the template, the mapping between the string in the template and the translation in the .xtb file is corrupted.
How can I change the brand as suggested by Asesh in the link above and still have everything properly translated?
I have tried to modify the xtb files with my new brand name as well but the mapping did not work out between the id and the string in the template. I have read about GRIT but if I got it right, I cannot use the grit tool that comes with Chromium to just generate new numerical ids for the translations.
I'm getting this log warning while using my app and I'm not sure how to deal with this message:
2014-10-21 12:57:54.472 App[7067:2540152] Localizable string "(A Document Being Saved By %#)" not found in strings table "Document" of bundle CFBundle 0x12e508f60 (not loaded).
It seems, the localization file within the framework is missing, which would be really weird. Re-adding the framework didn't help.
Any hints apprechiated.
I'm getting the same message. In my case it looks like both TestFlight and Crashlytics are generating them;
[TestFlight takeOff:#"xxxxxxxxxxx"]; // Generates 2 messages
[Crashlytics startWithAPIKey:#"xxxxxxxxxxx"]; // Generates 1 message
Not causing us any trouble, so leaving them alone for now.
Update
Ok, got to the bottom of it. If you've been doing localization, chances are you probably enabled 'Localization Debugging' in your scheme (Product > Scheme > Edit Scheme in Xcode). If you're wondering why you're getting these messages from the various libraries, it's probably because you still have it enabled.
I just had this problem too.
Since turning off the warning seems like a bad idea (Feels like high risk translations will not work as intended), I tracked down what actually caused the problem.
In my case, the problem was an empty string in the Localizable.strings file. (I used a non-standard way to generate it, the default genstrings tool will not add them)
That is, in one place I had this line:
/* No comment provided by engineer. */
"" = "";
If I removed it, the warning disappeared!
Seems like there is some problem in the string table implementation if you add empty strings, that makes all string tables mess up, not only the one where the problem is...
Maybe someone will find this information useful, so I leave it here.
If you don't specify "Document" then it will look in the file Localizable.strings. Otherwise make sure you have the file Document.strings in your project. Also, "(A Document Being Saved By %#)" looks pretty weird to me. You might want to check this is really what you want as a key for a localizable string.
Here is a link that may help you understand the process
https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/LoadingResources/Strings/Strings.html
From what i found in my recent project, this error occured when you have the english language (just english with no region) defined in your device.
Since one or more framework will fail to find translation strings you will have this error in your console log.
Hope that helps
Another common mistake is the forgotten ";" at the end of any line in the file, that holds your Localizable.strings. This can easily happen after massive copy and paste. Unfortunately it is not easy to locate, because the compiler does not complain with a line number or any other helpful hint. This can be very painful and tedious, when you have big localizable tables.
The result of that mistake will be, that some translations are found, others not and its hard to find the reason.
My solution to make sure, all keys are proper defined (with the ";" at the end of the line):
Open your file "Localizable.strings" in Xcode
Delete the lower half of the table (for a start)
Press COMMAND + B (build)
If you don't get an error, the problem must be in the deleted lower half. Paste it back, delete now only the lower 25 % and repeat build. Repeat the process until you can better locate the problem.
Looked all over StackOverflow looking for a solution.
And found a mistake.
I just duplicated the localization, for example:
let str = "String".localized
After that, as well:
str.localized
And after that I claim
[strings] ERROR: String not found in table Localizable of bundle
CFBundle 0x14bd01fc0
I'm planning to do a program with Lua that will first of all read specific files
and get information from those files. So my first question is whats the "my documents" path name? I have searched a lot of places, but I'm unable to find anything. My second question is how can I use the first four letters of a file name to see which one is the newest made?
Finding the files in "my documents" then find the newest created file and read it.
The reading part shouldn't be a problem, but navigating to "my documents" and finding the newest created file in a folder.
For your first question, depends how robust you want your script to be. You could use Lua's builtin os.getenv() to get a variety of environment vars related to user, such as USERNAME, USERPROFILE, HOMEDRIVE, HOMEPATH. Example:
username = os.getenv('USERNAME')
dir = 'C:\\users\\' .. username .. '\\Documents'
For the second question, there is no builtin mechanism in Windows to have the file creation or modification timestamp as part of the filename. You could read the creation or modification timestamp, via a C extension you create or using an existing Lua library like lfs. Or you could read the contents of a folder and parse the filenames if they were named according to the pattern you mention. Again there is nothing built into Lua to do this, you would either use os.execute() or lfs or, again, your own C extension module, or combinations of these.
Note: I'm not a RoR developer, so if there is anything inaccurate in the question please correct me.
RoR has its own i18n library. This library (optionally) uses YAML format for the localization files. In these localization files, key-value pairs are used where the value is the translation provided, but these key-value pairs can be within a scope (namespace), here are exapmles:
One example from here - http://guides.rubyonrails.org/i18n.html
pt:
foo:
bar: baz
... the top level key is the locale. :foo is a namespace key and :bar
is the key for the translation “baz”.
And another exapmle from here - http://ruby-on-rails-tutorials.blogspot.com/2010/11/i18n-in-rails3.html
en:
contact:
prices:
show_price: "%{price_dollar}$"
quote: "Coordinator: & quot;Crucifixion?& quot? & lt;br /& gt; Mr. Cheeky: & quot;Er, no, freedom actually.& quot;"
attributes:
created_at: "Created at"
updated_at: "Updated at"
helpers:
submit:
contact:
create: "Order"
update: "Modify"
label:
contact:
name: "Your name"
company_name: "Company name"
phone: "Phone number"
email: "E-mail"
comment: "Comment"
Please check the pointers for better explanation.
An alternative style one can think of is to flatten the scope attributes: for example, in the last quote we can say:
helpers.label.contact.company_name: "Company name"
I believe that the nested style can be very confusing when editing large or deeply nested localization files. And indeed I found a couple of places where this issue is raised:
accessing I18n translations yamls - a thread complaining about this same issue on the rails-i18n group.
The reason of doing it was complications I met with working on huge
piece of data in nested yml files. Having few thousands keys in few
translations files, was making me furious when I needed rename
translation keys, move them to another namespace etc. and had to
scroll a lot, looking and wondering what is namespace of the key.
Also, resolving merge conflicts, checking for missing translations in
other locale files are much easier, when you have and see full key.
And here: https://github.com/henrik/vim-yaml-flattener someone has written a Vim plugin to flatten the file back and forth to overcome the issue.
My question is: what exactly are the advantages of having the nested style. Is there any issues with the flat style that made the developers go with the nested style despite the drawbacks?
I wrote the YAML flattener plugin for Vim.
The main reason for the nested format, to me, is that it's conventional, so any tools or services we may want to use are likely to use that format.
I suppose there is some risk of making typos as you start repeating yourself, and renaming things means renaming them in multiple places – but they're also harder to find to rename, and your editor likely has good tools to rename in batch.
I could come up with more reasons (shorter lines, smaller files, less noisy diffs) but I don't think they're very important.
It's a good question. I'm considering using the flat format most of the time and only converting if I need to use an external tool.
For me, the main benefit of the layout of YAML files is that it's quite easy at a glance to see the relationships between the configuration data. I spent a few years working with Python, which defines scope with white space rather than extraneous characters like {}, etc, so the paradigm is comfortable for me.
Arguably, if you have large yaml files...thousands of keys...then it's probably time to start breaking up the files into smaller, more manageable files. When I am writing code in general and I get a file of ANY sort that is that large, I refactor mercilessly to organize things more intuitively.
Largely this is druthers, I suppose.
We have two .po files, each from different branches of a piece of software.
We need to combine these into a single .po file.
There are duplicates between the two files, and the ideal handling would be for one file's strings to be favoured (consistently).
We have a SUSE system so the --output-file doesn't seem to have the behaviour of ignoring/merging duplicates which the Sun version has according to a man page I found from a web search. (We do not have a Sun machine handy!)
What you are looking for is the msgcat util, it concatenates and merges the specified PO dictionaries.
This is part of gettext utils, for more information please consult gettext manual page on msgcat.
you can use poedit.
To merge your current po-file, you must to open it and click:
Catalog > Update from POT-file.
Set the filter to all files and select your second.po file
Poedit will show you new & obsolete strings
I use msgmerge:
msgmerge [old_file.po] [new_file.po] > output.po
It works for me, but be aware that it does a silly merge, it is, it discards the entries in the old_file (new file items overwrites old one items).