Comment 1 by jteh on 2012-10-25 01:41
There are already translations for other languages in the repository. If you want to send me a translated PO file, I can commit it. However, I guess it's not part of the automated system.

Mesar, how do we go about getting this into the automated system? The repository is at http://bzr.nvaccess.org/nvda-ocr/

Comment 2 by jteh on 2012-11-22 07:09
Mesar, ping? Tesseract 3.02 is now out, so I'd like to update this add-on, but it'd make sense to get it into the automated translated system while we're at it.

Comment 3 by ragb on 2012-11-22 12:56
Hi,

Probably we should consider using the add-on template we've bee using on other plugins (see https://bitbucket.org/nvdaaddonteam/addon-template).

Further then creating the add-on and such using scons, I implemented a way to generate translated manifest files from gettext mo files, so we can avoid most of the encoding problems translators caused (by accident).

It's kind of hackish but I've been using similar code on my add-ons quite successfully.

as you have much more expirience with scons than me, maybe you can improove it further (or say that i does suit at all :)).

Comment 4 by jteh (in reply to comment 3) on 2012-11-22 19:33
Replying to ragb:

Further then creating the add-on and such using scons,

The way this add-on is built is going to need some pretty serious tweaking, as it needs to copy in other modules, handle Tesseract, etc.

I implemented a way to generate translated manifest files from gettext mo files, so we can avoid most of the encoding problems translators caused (by accident).

Perhaps I'm misunderstanding, but this seems like a long way to work around the problem. The only reason we don't have encoding problems with po files is that msgfmt won't build them if they're broken. We could just implement similar checks for manifest files at build time.

If there are other good reasons to use gettext for manifests, why wasn't this proposed instead of the locale specific manifest.ini files? Perhaps it wasn't thought of back then, which is fine.

Comment 5 by jteh on 2012-11-22 19:42
One issue I see with the template is that I think the manifest strings are stored in the main po file for the add-on, which means we have two copies of these strings in memory: one in the manifest and one in gettext. I guess this doesn't matter that much, but it's a bit redundant/wasteful.

Comment 6 by ragb (in reply to comment 4) on 2012-11-22 19:49
Replying to jteh:

Replying to ragb:

Further then creating the add-on and such using scons,

The way this add-on is built is going to need some pretty serious tweaking, as it needs to copy in other modules, handle Tesseract, etc.

Of course. The temlate is just a base that can be used as is for simple add-ons.

I implemented a way to generate translated manifest files from gettext mo files, so we can avoid most of the encoding problems translators caused (by accident).

Perhaps I'm misunderstanding, but this seems like a long way to work around the problem. The only reason we don't have encoding problems with po files is that msgfmt won't build them if they're broken. We could just implement similar checks for manifest files at build time.

Yes. However manifests have been causing some more trouble to translators, further than encoding (i.g. quotes not close, extra fields added - which cause no harm but they tend to put there), etc). My point (and Mesar's at least) was more of users just using one format so they won't get more confused.

Anyhow, we could check the manifests at buiild time. My rational was more to help trnaslators then a techincal feature of the build system.

If there are other good reasons to use gettext for manifests, why wasn't this proposed instead of the locale specific manifest.ini files? Perhaps it wasn't thought of back then, which is fine.

Yes. I guess noone would expected these problems.

Comment 7 by ragb (in reply to comment 5) on 2012-11-22 19:55
Replying to jteh:

One issue I see with the template is that I think the manifest strings are stored in the main po file for the add-on, which means we have two copies of these strings in memory: one in the manifest and one in gettext. I guess this doesn't matter that much, but it's a bit redundant/wasteful.

True. We could generate an extra .po gettext file for this porpose, but honestly I don't think two more strings in memory deserve that extra build work. Further more translators would have an extra po file to translate. This extra file won't be included in the packaged add-on, however.

Comment 8 by MHameed on 2013-01-23 06:10
Sorry for not getting back to this sooner, has a consensus been reached?
If so please do use the addon template/do the needed tweeking, and we can include it into the translation system.

Thanks.

CC @josephsl and @jcsteh to kindly request further discussion on getting the OCR add-on part of NVDA's automated translation system, assuming that it isn't already.

Honestly, I belief it would be best to move issues regarding de OCR add-on to its repository on Github.

Closing. See NVAccess/NVDA-OCR/#4