Hi,
I'm a relatively new user to ODK, and though I've searched the group
for replies on the issues below, I haven't seen clarifying responses
(but sorry if I've simply missed them):
- We are implementing surveys in multiple languages (french, haitian
creole, arabic, english, maybe more) ane ond of the important issues
that we're encountering is that, although it is working to create
labels, hints and choice lists in various languages, we are having
trouble employing ODK's higher functions (things like loops) in non-
English languages because these functions tend to generate pop-up text
that is in English. Even when the android phone's language setting
is changed to French or Spanish, only SOME of the prompts, buttons, or
supplementary instructions in ODK are translated. Many remain in
English. The result can be a strange mix, where three buttons will
pop up on screen, one in English, one in French, and one in English.
The question: are we doing something wrong? do we need to change
settings on the phone? in ODK? in both? remember: we've already
taken the step of writing all questions, hints, and choices in the
various languages.
- one of the languages we are implementing in is arabic. We have
been able to, by rooting the phones and using cyanogen mod, install a
version of Android that has arabic support. But this still has at
least one problem (in addition to the above): the arabic text has
errors in it's "calligraphy". I am not an arabic speaker, the but the
experts we talk to say that, essentially, letters that should be
connected are not, resulting in strange breaks. The problem is
perhaps analagous to taking a document in times font, and switching to
calibri, and suddenly discovering that the last letter of some words
is capitalized, in gothic font, and maybe has an added space before
it. The arabic experts predict that enumerators can work around this
problem, but that it will be awkward, to say the least.
Q: has anyone else seen or reported a similar problem? found a
solution? assuming no, then does Android / ODK plan some kind of
support for arabic in future versions which may improve the
situation?
Many thanks for your consideration...
edwin
Hi Edwin,
We set up some forms in Amharic and Tigrinyan - Ethiopian languages
which use the Ge'ez script (a non-latin script)... and had some 'fun'
figuring out why the forms weren't displaying correctly, so maybe our
experiences will help ...
-
some pops ups/prompts appearing in English even after selecting
phone language. There's more info here:
http://groups.google.com/group/opendatakit-developers/browse_thread/thread/f05b71dac58e6ea9/749a20055b9889df?lnk=gst&q=strings.xml#749a20055b9889df.
Basically you'll need to download the ODKCollect code, put the (new)
translated strings.xml file into the right place and recompile for
installing on the phones.
-
None of the standard Android ROMs include support for Ge'ez, so we
too installed the cyanogen ROM (v7.1.0 I think), and added a system
font file which included support for Ge'ez, then everything worked ok.
However, with the new system font file I did notice an issue with
spacing when using cyrillic characters - the letters are all double
spaced. This is an issue with the particular font file we used.
So .... it may be that you could download and use another arabic font
file (rather than the default one in Cyanogen) and may resolve the
spacing issue?
Another possibility is something else we noticed with our Ge'ez font
file: there was no support for bold characters... so on ODK all the
questions appeared as missing character squares - the solution for us
was to change the question font style (in ODK Collect code) to use
normal rather than bold. Perhaps in your arabic font file, support for
bold characters exists, but isn't great, so you could try changing to
using normal font style to see what different that makes. A quick way
to test this (without recompiling the ODK Collect code) is to see if
the spacing is an issue in the questions and response options in your
forms. If it's only on the question (and not the response option) it
could well be the bold issue. If the issue is on both question and
response options, it;s perhaps more likely to be the system font file.
So the issues we found were less to do with ODK Collect directly and
more because of the Android system fonts.
Sorry these aren't definitive answers for you, but maybe gives some
pointers where to start looking 
Cheers,
Alex
···
On Nov 2, 10:35 pm, Edwin Adkins wrote:
> Hi,
>
> I'm a relatively new user to ODK, and though I've searched the group
> for replies on the issues below, I haven't seen clarifying responses
> (but sorry if I've simply missed them):
>
> 1) We are implementing surveys in multiple languages (french, haitian
> creole, arabic, english, maybe more) ane ond of the important issues
> that we're encountering is that, although it is working to create
> labels, hints and choice lists in various languages, we are having
> trouble employing ODK's higher functions (things like loops) in non-
> English languages because these functions tend to generate pop-up text
> that is in English. *Even when the android phone's language setting
> is changed to French or Spanish, only SOME of the prompts, buttons, or
> supplementary instructions in ODK are translated. Many remain in
> English.* The result can be a strange mix, where three buttons will
> pop up on screen, one in English, one in French, and one in English.
>
> The question: are we doing something wrong? do we need to change
> settings on the phone? in ODK? in both? remember: we've already
> taken the step of writing all questions, hints, and choices in the
> various languages.
>
> 2) one of the languages we are implementing in is arabic. We have
> been able to, by rooting the phones and using cyanogen mod, install a
> version of Android that has arabic support. But this still has at
> least one problem (in addition to the above): the arabic text has
> errors in it's "calligraphy". I am not an arabic speaker, the but the
> experts we talk to say that, essentially, letters that should be
> connected are not, resulting in strange breaks. The problem is
> perhaps analagous to taking a document in times font, and switching to
> calibri, and suddenly discovering that the last letter of some words
> is capitalized, in gothic font, and maybe has an added space before
> it. The arabic experts predict that enumerators can work around this
> problem, but that it will be awkward, to say the least.
>
> Q: has anyone else seen or reported a similar problem? found a
> solution? assuming no, then does Android / ODK plan some kind of
> support for arabic in future versions which may improve the
> situation?
>
> Many thanks for your consideration...
>
> edwin
until that happens, your best bet is to use the multimedia
functionality we have to display screenshots of your prompts. type
questions in arabic on computer, take a screenshot, and use that image
instead of plain old question text.
I think it would be amazing to create a tool that actually takes some text
and spits out an image of the text rendered properly, and we can put that
image in a form (rather than taking screenshots by hand). One of the nice
things about Opera Mini is that it does image-based rendering for fonts
that a phone might not support, and I think it has done a lot for phones
supporting non-Latin characters; would be great to bring this to ODK.
Anyone on the list have pointers to somewhere one might get started on a
feature like this?
--prabhas
we put as much localization into the collect application as we could
source from the community, but as you saw, there are lots of gaps.
one thing that we need help with is setting up a better localization
structure where everyone could contribute.
http://crowdin.net/page/android-localization provides such a
structure, so if someone is interested in helping us localize 1.1.7
that way, please let me know. it's not a very technical task, it'd be
helpful if said person has some programming experience.
as far as script support, android has varying support for fonts for
arabic and hindi, but their layout engine is broken (see
http://code.google.com/p/android/issues/detail?id=5597). that's why
you can see the letters, but they don't really make sense. you can try
http://ardoid.com to see if that works better.
when android supports scripts properly, odk will automatically work.
until that happens, your best bet is to use the multimedia
functionality we have to display screenshots of your prompts. type
questions in arabic on computer, take a screenshot, and use that image
instead of plain old question text.
yaw
···
On Thu, Nov 3, 2011 at 18:10, Alex Little wrote:
> Hi Edwin,
>
> We set up some forms in Amharic and Tigrinyan - Ethiopian languages
> which use the Ge'ez script (a non-latin script)... and had some 'fun'
> figuring out why the forms weren't displaying correctly, so maybe our
> experiences will help ...
>
> 1) some pops ups/prompts appearing in English even after selecting
> phone language. There's more info here:
> http://groups.google.com/group/opendatakit-developers/browse_thread/thread/f05b71dac58e6ea9/749a20055b9889df?lnk=gst&q=strings.xml#749a20055b9889df.
> Basically you'll need to download the ODKCollect code, put the (new)
> translated strings.xml file into the right place and recompile for
> installing on the phones.
>
> 2) None of the standard Android ROMs include support for Ge'ez, so we
> too installed the cyanogen ROM (v7.1.0 I think), and added a system
> font file which included support for Ge'ez, then everything worked ok.
> However, with the new system font file I did notice an issue with
> spacing when using cyrillic characters - the letters are all double
> spaced. This is an issue with the particular font file we used.
> So .... it may be that you could download and use another arabic font
> file (rather than the default one in Cyanogen) and may resolve the
> spacing issue?
>
> Another possibility is something else we noticed with our Ge'ez font
> file: there was no support for bold characters... so on ODK all the
> questions appeared as missing character squares - the solution for us
> was to change the question font style (in ODK Collect code) to use
> normal rather than bold. Perhaps in your arabic font file, support for
> bold characters exists, but isn't great, so you could try changing to
> using normal font style to see what different that makes. A quick way
> to test this (without recompiling the ODK Collect code) is to see if
> the spacing is an issue in the questions and response options in your
> forms. If it's only on the question (and not the response option) it
> could well be the bold issue. If the issue is on both question and
> response options, it;s perhaps more likely to be the system font file.
>
> So the issues we found were less to do with ODK Collect directly and
> more because of the Android system fonts.
>
> Sorry these aren't definitive answers for you, but maybe gives some
> pointers where to start looking :-)
>
> Cheers,
> Alex
>
> On Nov 2, 10:35 pm, Edwin Adkins wrote:
>> Hi,
>>
>> I'm a relatively new user to ODK, and though I've searched the group
>> for replies on the issues below, I haven't seen clarifying responses
>> (but sorry if I've simply missed them):
>>
>> 1) We are implementing surveys in multiple languages (french, haitian
>> creole, arabic, english, maybe more) ane ond of the important issues
>> that we're encountering is that, although it is working to create
>> labels, hints and choice lists in various languages, we are having
>> trouble employing ODK's higher functions (things like loops) in non-
>> English languages because these functions tend to generate pop-up text
>> that is in English. *Even when the android phone's language setting
>> is changed to French or Spanish, only SOME of the prompts, buttons, or
>> supplementary instructions in ODK are translated. Many remain in
>> English.* The result can be a strange mix, where three buttons will
>> pop up on screen, one in English, one in French, and one in English.
>>
>> The question: are we doing something wrong? do we need to change
>> settings on the phone? in ODK? in both? remember: we've already
>> taken the step of writing all questions, hints, and choices in the
>> various languages.
>>
>> 2) one of the languages we are implementing in is arabic. We have
>> been able to, by rooting the phones and using cyanogen mod, install a
>> version of Android that has arabic support. But this still has at
>> least one problem (in addition to the above): the arabic text has
>> errors in it's "calligraphy". I am not an arabic speaker, the but the
>> experts we talk to say that, essentially, letters that should be
>> connected are not, resulting in strange breaks. The problem is
>> perhaps analagous to taking a document in times font, and switching to
>> calibri, and suddenly discovering that the last letter of some words
>> is capitalized, in gothic font, and maybe has an added space before
>> it. The arabic experts predict that enumerators can work around this
>> problem, but that it will be awkward, to say the least.
>>
>> Q: has anyone else seen or reported a similar problem? found a
>> solution? assuming no, then does Android / ODK plan some kind of
>> support for arabic in future versions which may improve the
>> situation?
>>
>> Many thanks for your consideration...
>>
>> edwin
>
> --
> Post: opendatakit@googlegroups.com
> Unsubscribe: opendatakit+unsubscribe@googlegroups.com
> Options: http://groups.google.com/group/opendatakit?hl=en
>
i bet it'd be pretty easy to write a small java app that takes some
text and spits out an jpg. perhaps ask on http://stackoverflow.com to
get started...
···
On Tue, Nov 8, 2011 at 04:23, Prabhas Pokharel wrote:
>> until that happens, your best bet is to use the multimedia
>> functionality we have to display screenshots of your prompts. type
>> questions in arabic on computer, take a screenshot, and use that image
>> instead of plain old question text.
>
> I think it would be amazing to create a tool that actually takes some text
> and spits out an image of the text rendered properly, and we can put that
> image in a form (rather than taking screenshots by hand). One of the nice
> things about Opera Mini is that it does image-based rendering for fonts that
> a phone might not support, and I think it has done a lot for phones
> supporting non-Latin characters; would be great to bring this to ODK.
> Anyone on the list have pointers to somewhere one might get started on a
> feature like this?
> --prabhas
>
> --
> Post: opendatakit@googlegroups.com
> Unsubscribe: opendatakit+unsubscribe@googlegroups.com
> Options: http://groups.google.com/group/opendatakit?hl=en
>
Interesting solution... Here is one potential (non-developer) resource
for Text to Image processing:
http://www.text2image.com/pal_t2i/saver_en.do
maybe slightly faster than manual screen capture, and gives you control
over dimensions, background color, etc.
If nothing else, gives a nice framework for requirements.
More technically:
In Ruby the gem is RMagick, and there are versions for PHP and Java as
well.
http://www.imagemagick.org/RMagick/doc/
···
On Mon, Nov 7, 2011 at 6:53 PM, Yaw Anokwa wrote:
i bet it'd be pretty easy to write a small java app that takes some
text and spits out an jpg. perhaps ask on http://stackoverflow.com to
get started...
On Tue, Nov 8, 2011 at 04:23, Prabhas Pokharel prabhas.pokharel@gmail.com wrote:
until that happens, your best bet is to use the multimedia
functionality we have to display screenshots of your prompts. type
questions in arabic on computer, take a screenshot, and use that image
instead of plain old question text.
I think it would be amazing to create a tool that actually takes some
text
and spits out an image of the text rendered properly, and we can put that
image in a form (rather than taking screenshots by hand). One of the nice
things about Opera Mini is that it does image-based rendering for fonts
that
a phone might not support, and I think it has done a lot for phones
supporting non-Latin characters; would be great to bring this to ODK.
Anyone on the list have pointers to somewhere one might get started on a
feature like this?
--prabhas
--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en
--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en
--
James Dailey
skype: jdailey