For a project KoBoToolbox is implementing, we ran into a limitation with
language names. We'd like to propose a slight difference in recommending
language name usage in XForms/XLSForms. Instead of e.g. “Français”, we
could recommend that users start using a two-part string with a “__"
separator e.g. “fr__Français".
The first part is the valid (2 or 3 character) IANA subtag http://www.iana.org/assignments/language-subtag-registry/language-subtag-registry.
The second part is the language name that should be displayed in a language
switcher on the client (could be in any spelling variant). So, if ‘ar_
العربية‘ is used, the language switcher would just show العربية.
Advantages:
The client's awareness of the actual language code will allow a
future feature that automatically matches the form language with the
UI/browser/OS language or vice versa.
It will allow web clients to create valid lang attributes. “French”
is not a valid value. “fr” is a valid value.
Old forms won’t break if we would start recommending this. We’d just,
ideally, have to add some logic to Collect/Enketo/Other clients that checks
whether the language name includes ‘__’ and if so, displays only the second
part in the language switcher.
Any interest in supporting this or any suggestions for an alternative
approach?
Seems reasonable to me. Only nit is why a double underscore instead of a single?
Yaw
···
--
Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.
On Thu, Jul 23, 2015 at 6:49 PM, Martijn van de Rijdt martijn@enketo.org wrote:
Hi ODK devs,
For a project KoBoToolbox is implementing, we ran into a limitation with
language names. We'd like to propose a slight difference in recommending
language name usage in XForms/XLSForms. Instead of e.g. “Français”, we could
recommend that users start using a two-part string with a “__" separator
e.g. “fr__Français".
The first part is the valid (2 or 3 character) IANA subtag. The second part
is the language name that should be displayed in a language switcher on the
client (could be in any spelling variant). So, if ‘ar_العربية‘ is used, the
language switcher would just show العربية.
Advantages:
The client's awareness of the actual language code will allow a future
feature that automatically matches the form language with the UI/browser/OS
language or vice versa.
It will allow web clients to create valid lang attributes. “French” is not
a valid value. “fr” is a valid value.
Old forms won’t break if we would start recommending this. We’d just,
ideally, have to add some logic to Collect/Enketo/Other clients that checks
whether the language name includes ‘__’ and if so, displays only the second
part in the language switcher.
Any interest in supporting this or any suggestions for an alternative
approach?
Also seems reasonable to me. And I guess the double underscore makes it
less likely that we misfire and start hacking off the first part of a
language name that had an _ for other reasons. I'd hate for this to cause
us a bunch of backward-compatibility support issues.
One idea might be to put the subtag second. We have lots of people who have
devices with old versions of Collect, e.g., even after they've upgraded
most or all of their other system components. The question is whether
"fr__French" or "French__fr" is the friendlier thing to show in the
language selector for such cases. And I'd argue that the latter is slightly
more friendly.
For that matter, the friendliest would be "French (fr)". So specifying the
subtag in a parenthetical could be another way to go, to be most friendly
for unsupporting clients.
Best,
Chris
···
---
Christopher Robert
Dobility, Inc. (SurveyCTO)
http://www.surveycto.com/
http://blog.surveycto.com/
Seems reasonable to me. Only nit is why a double underscore instead of a
single?
Yaw
Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.
On Thu, Jul 23, 2015 at 6:49 PM, Martijn van de Rijdt martijn@enketo.org wrote:
Hi ODK devs,
For a project KoBoToolbox is implementing, we ran into a limitation with
language names. We'd like to propose a slight difference in recommending
language name usage in XForms/XLSForms. Instead of e.g. “Français”, we
could
recommend that users start using a two-part string with a “__" separator
e.g. “fr__Français".
The first part is the valid (2 or 3 character) IANA subtag. The second
part
is the language name that should be displayed in a language switcher on
the
client (could be in any spelling variant). So, if ‘ar_العربية‘ is used,
the
language switcher would just show العربية.
Advantages:
The client's awareness of the actual language code will allow a future
feature that automatically matches the form language with the
UI/browser/OS
language or vice versa.
It will allow web clients to create valid lang attributes. “French” is
not
a valid value. “fr” is a valid value.
Old forms won’t break if we would start recommending this. We’d just,
ideally, have to add some logic to Collect/Enketo/Other clients that
checks
whether the language name includes ‘__’ and if so, displays only the
second
part in the language switcher.
Any interest in supporting this or any suggestions for an alternative
approach?
I'd vote for an option if we go this route that we also support just fr or
en and have ODK/Enketo do the match so we're consistent.
The nice thing about the approach right now is it allows people to make
mistakes and it still works. This is pretty helpful when you are
supporting weird language dialects
···
On Fri, Jul 24, 2015 at 1:43 PM, Christopher Robert wrote:
Also seems reasonable to me. And I guess the double underscore makes it
less likely that we misfire and start hacking off the first part of a
language name that had an _ for other reasons. I'd hate for this to cause
us a bunch of backward-compatibility support issues.
One idea might be to put the subtag second. We have lots of people who
have devices with old versions of Collect, e.g., even after they've
upgraded most or all of their other system components. The question is
whether "fr__French" or "French__fr" is the friendlier thing to show in the
language selector for such cases. And I'd argue that the latter is slightly
more friendly.
For that matter, the friendliest would be "French (fr)". So specifying the
subtag in a parenthetical could be another way to go, to be most friendly
for unsupporting clients.
Seems reasonable to me. Only nit is why a double underscore instead of a
single?
Yaw
Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.
On Thu, Jul 23, 2015 at 6:49 PM, Martijn van de Rijdt martijn@enketo.org wrote:
Hi ODK devs,
For a project KoBoToolbox is implementing, we ran into a limitation with
language names. We'd like to propose a slight difference in recommending
language name usage in XForms/XLSForms. Instead of e.g. “Français”, we
could
recommend that users start using a two-part string with a “__" separator
e.g. “fr__Français".
The first part is the valid (2 or 3 character) IANA subtag. The second
part
is the language name that should be displayed in a language switcher on
the
client (could be in any spelling variant). So, if ‘ar_العربية‘ is used,
the
language switcher would just show العربية.
Advantages:
The client's awareness of the actual language code will allow a future
feature that automatically matches the form language with the
UI/browser/OS
language or vice versa.
It will allow web clients to create valid lang attributes. “French”
is not
a valid value. “fr” is a valid value.
Old forms won’t break if we would start recommending this. We’d just,
ideally, have to add some logic to Collect/Enketo/Other clients that
checks
whether the language name includes ‘__’ and if so, displays only the
second
part in the language switcher.
Any interest in supporting this or any suggestions for an alternative
approach?
We might also want to support dialects. So for example:
en-AU_British English
en-US_Freedom English
Anything after the _ is shown to the user (e.g. Freedom English). And
if that description isn't there, clients can pull the language
description from somewhere else.
···
On Fri, Jul 24, 2015 at 5:58 AM, Matt Berg wrote:
> Agree i don't like the double underscore.
>
> I'd vote for an option if we go this route that we also support just fr or
> en and have ODK/Enketo do the match so we're consistent.
>
> The nice thing about the approach right now is it allows people to make
> mistakes and it still works. This is pretty helpful when you are supporting
> weird language dialects
>
> On Fri, Jul 24, 2015 at 1:43 PM, Christopher Robert wrote:
>>
>> Also seems reasonable to me. And I guess the double underscore makes it
>> less likely that we misfire and start hacking off the first part of a
>> language name that had an _ for other reasons. I'd hate for this to cause us
>> a bunch of backward-compatibility support issues.
>>
>> One idea might be to put the subtag second. We have lots of people who
>> have devices with old versions of Collect, e.g., even after they've upgraded
>> most or all of their other system components. The question is whether
>> "fr__French" or "French__fr" is the friendlier thing to show in the language
>> selector for such cases. And I'd argue that the latter is slightly more
>> friendly.
>>
>> For that matter, the friendliest would be "French (fr)". So specifying the
>> subtag in a parenthetical could be another way to go, to be most friendly
>> for unsupporting clients.
>>
>> Best,
>>
>> Chris
>>
>> ---
>> Christopher Robert
>> Dobility, Inc. (SurveyCTO)
>> http://www.surveycto.com/
>> http://blog.surveycto.com/
>>
>> On Thu, Jul 23, 2015 at 10:34 PM Yaw Anokwa wrote:
>>>
>>> Martijn,
>>>
>>> Seems reasonable to me. Only nit is why a double underscore instead of a
>>> single?
>>>
>>> Yaw
>>> --
>>> Need ODK services? http://nafundi.com provides form design, server
>>> setup, professional support, and software development for ODK.
>>>
>>> On Thu, Jul 23, 2015 at 6:49 PM, Martijn van de Rijdt wrote:
>>> > Hi ODK devs,
>>> >
>>> >
>>> > For a project KoBoToolbox is implementing, we ran into a limitation
>>> > with
>>> > language names. We'd like to propose a slight difference in
>>> > recommending
>>> > language name usage in XForms/XLSForms. Instead of e.g. “Français”, we
>>> > could
>>> > recommend that users start using a two-part string with a “__"
>>> > separator
>>> > e.g. “fr__Français".
>>> >
>>> >
>>> > The first part is the valid (2 or 3 character) IANA subtag. The second
>>> > part
>>> > is the language name that should be displayed in a language switcher on
>>> > the
>>> > client (could be in any spelling variant). So, if ‘ar_العربية‘ is used,
>>> > the
>>> > language switcher would just show العربية.
>>> >
>>> >
>>> > Advantages:
>>> >
>>> > The client's awareness of the actual language code will allow a future
>>> > feature that automatically matches the form language with the
>>> > UI/browser/OS
>>> > language or vice versa.
>>> > It will allow web clients to create valid `lang` attributes. “French”
>>> > is not
>>> > a valid value. “fr” is a valid value.
>>> >
>>> > Old forms won’t break if we would start recommending this. We’d just,
>>> > ideally, have to add some logic to Collect/Enketo/Other clients that
>>> > checks
>>> > whether the language name includes ‘__’ and if so, displays only the
>>> > second
>>> > part in the language switcher.
>>> >
>>> >
>>> > Any interest in supporting this or any suggestions for an alternative
>>> > approach?
>>> >
>>> >
>>> > Cheers,
>>> >
>>> > Martijn
>>> >
>>> >
>>> > --
>>> > Revolutionizing data collection since 2012.
>>> >
>>> > Enketo | LinkedIn | GitHub | Twitter | Blog
>>> >
>>> > --
>>> > You received this message because you are subscribed to the Google
>>> > Groups
>>> > "ODK Developers" group.
>>> > To unsubscribe from this group and stop receiving emails from it, send
>>> > an
>>> > email to opendatakit-developers+unsubscribe@googlegroups.com.
>>> > For more options, visit https://groups.google.com/d/optout.
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "ODK Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to opendatakit-developers+unsubscribe@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "ODK Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to opendatakit-developers+unsubscribe@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "ODK Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to opendatakit-developers+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
···
On Fri, Jul 24, 2015 at 2:38 PM, Yaw Anokwa wrote:
We might also want to support dialects. So for example:
en-AU_British English
en-US_Freedom English
Anything after the _ is shown to the user (e.g. Freedom English). And
if that description isn't there, clients can pull the language
description from somewhere else.
On Fri, Jul 24, 2015 at 5:58 AM, Matt Berg mlberg@gmail.com wrote:
Agree i don't like the double underscore.
I'd vote for an option if we go this route that we also support just fr
or
en and have ODK/Enketo do the match so we're consistent.
The nice thing about the approach right now is it allows people to make
mistakes and it still works. This is pretty helpful when you are
supporting
weird language dialects
Also seems reasonable to me. And I guess the double underscore makes it
less likely that we misfire and start hacking off the first part of a
language name that had an _ for other reasons. I'd hate for this to
cause us
a bunch of backward-compatibility support issues.
One idea might be to put the subtag second. We have lots of people who
have devices with old versions of Collect, e.g., even after they've
upgraded
most or all of their other system components. The question is whether
"fr__French" or "French__fr" is the friendlier thing to show in the
language
selector for such cases. And I'd argue that the latter is slightly more
friendly.
For that matter, the friendliest would be "French (fr)". So specifying
the
subtag in a parenthetical could be another way to go, to be most
friendly
for unsupporting clients.
Seems reasonable to me. Only nit is why a double underscore instead of
a
single?
Yaw
Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.
On Thu, Jul 23, 2015 at 6:49 PM, Martijn van de Rijdt martijn@enketo.org wrote:
Hi ODK devs,
For a project KoBoToolbox is implementing, we ran into a limitation
with
language names. We'd like to propose a slight difference in
recommending
language name usage in XForms/XLSForms. Instead of e.g. “Français”,
we
could
recommend that users start using a two-part string with a “__"
separator
e.g. “fr__Français".
The first part is the valid (2 or 3 character) IANA subtag. The
second
part
is the language name that should be displayed in a language switcher
on
the
client (could be in any spelling variant). So, if ‘ar_العربية‘ is
used,
the
language switcher would just show العربية.
Advantages:
The client's awareness of the actual language code will allow a
future
feature that automatically matches the form language with the
UI/browser/OS
language or vice versa.
It will allow web clients to create valid lang attributes. “French”
is not
a valid value. “fr” is a valid value.
Old forms won’t break if we would start recommending this. We’d just,
ideally, have to add some logic to Collect/Enketo/Other clients that
checks
whether the language name includes ‘__’ and if so, displays only the
second
part in the language switcher.
Any interest in supporting this or any suggestions for an alternative
approach?
I neglected to mention we wanted to add support for spaces in languages
names with a single underscore like "pbt__Southern_Pastho" assuming spaces
would be a problem in Pyxform column headings. However, apparently spaces
are fine so that negates the need for a double underscore.
(1) "en-GB_Proper English" and "en_Proper English" syntax seems fine with
me
(2) additional support for just tags such as "pbt" or "en-GB" (and trying
to find a match for the display name) seems fine with me too
(3) and then the existing usage with e.g. "English" where the client can
try to make a match to get the tag (if the client wants to).
The backwards compatibility issue if underscores have been used in language
names in the past won't break forms, just the language display name in the
language selector. Is that acceptable, or do we need a different separator?
···
On Friday, July 24, 2015 at 5:48:21 AM UTC-6, Matt Berg wrote:
>
> en_US-Merica!
>
>
>
> On Fri, Jul 24, 2015 at 2:38 PM, Yaw Anokwa <yan...@nafundi.com > wrote:
>
>> We might also want to support dialects. So for example:
>> en-AU_British English
>> en-US_Freedom English
>>
>> Anything after the _ is shown to the user (e.g. Freedom English). And
>> if that description isn't there, clients can pull the language
>> description from somewhere else.
>>
>> On Fri, Jul 24, 2015 at 5:58 AM, Matt Berg <mlb...@gmail.com > wrote:
>> > Agree i don't like the double underscore.
>> >
>> > I'd vote for an option if we go this route that we also support just fr
>> or
>> > en and have ODK/Enketo do the match so we're consistent.
>> >
>> > The nice thing about the approach right now is it allows people to make
>> > mistakes and it still works. This is pretty helpful when you are
>> supporting
>> > weird language dialects
>> >
>> > On Fri, Jul 24, 2015 at 1:43 PM, Christopher Robert < cro...@surveycto.com > wrote:
>> >>
>> >> Also seems reasonable to me. And I guess the double underscore makes it
>> >> less likely that we misfire and start hacking off the first part of a
>> >> language name that had an _ for other reasons. I'd hate for this to
>> cause us
>> >> a bunch of backward-compatibility support issues.
>> >>
>> >> One idea might be to put the subtag second. We have lots of people who
>> >> have devices with old versions of Collect, e.g., even after they've
>> upgraded
>> >> most or all of their other system components. The question is whether
>> >> "fr__French" or "French__fr" is the friendlier thing to show in the
>> language
>> >> selector for such cases. And I'd argue that the latter is slightly more
>> >> friendly.
>> >>
>> >> For that matter, the friendliest would be "French (fr)". So specifying
>> the
>> >> subtag in a parenthetical could be another way to go, to be most
>> friendly
>> >> for unsupporting clients.
>> >>
>> >> Best,
>> >>
>> >> Chris
>> >>
>> >> ---
>> >> Christopher Robert
>> >> Dobility, Inc. (SurveyCTO)
>> >> http://www.surveycto.com/
>> >> http://blog.surveycto.com/
>> >>
>> >> On Thu, Jul 23, 2015 at 10:34 PM Yaw Anokwa <yan...@nafundi.com > wrote:
>> >>>
>> >>> Martijn,
>> >>>
>> >>> Seems reasonable to me. Only nit is why a double underscore instead
>> of a
>> >>> single?
>> >>>
>> >>> Yaw
>> >>> --
>> >>> Need ODK services? http://nafundi.com provides form design, server
>> >>> setup, professional support, and software development for ODK.
>> >>>
>> >>> On Thu, Jul 23, 2015 at 6:49 PM, Martijn van de Rijdt <mar...@enketo.org > wrote:
>> >>> > Hi ODK devs,
>> >>> >
>> >>> >
>> >>> > For a project KoBoToolbox is implementing, we ran into a limitation
>> >>> > with
>> >>> > language names. We'd like to propose a slight difference in
>> >>> > recommending
>> >>> > language name usage in XForms/XLSForms. Instead of e.g. “Français”,
>> we
>> >>> > could
>> >>> > recommend that users start using a two-part string with a “__"
>> >>> > separator
>> >>> > e.g. “fr__Français".
>> >>> >
>> >>> >
>> >>> > The first part is the valid (2 or 3 character) IANA subtag. The
>> second
>> >>> > part
>> >>> > is the language name that should be displayed in a language
>> switcher on
>> >>> > the
>> >>> > client (could be in any spelling variant). So, if ‘ar_العربية‘ is
>> used,
>> >>> > the
>> >>> > language switcher would just show العربية.
>> >>> >
>> >>> >
>> >>> > Advantages:
>> >>> >
>> >>> > The client's awareness of the actual language code will allow a
>> future
>> >>> > feature that automatically matches the form language with the
>> >>> > UI/browser/OS
>> >>> > language or vice versa.
>> >>> > It will allow web clients to create valid `lang` attributes.
>> “French”
>> >>> > is not
>> >>> > a valid value. “fr” is a valid value.
>> >>> >
>> >>> > Old forms won’t break if we would start recommending this. We’d
>> just,
>> >>> > ideally, have to add some logic to Collect/Enketo/Other clients that
>> >>> > checks
>> >>> > whether the language name includes ‘__’ and if so, displays only the
>> >>> > second
>> >>> > part in the language switcher.
>> >>> >
>> >>> >
>> >>> > Any interest in supporting this or any suggestions for an
>> alternative
>> >>> > approach?
>> >>> >
>> >>> >
>> >>> > Cheers,
>> >>> >
>> >>> > Martijn
>> >>> >
>> >>> >
>> >>> > --
>> >>> > Revolutionizing data collection since 2012.
>> >>> >
>> >>> > Enketo | LinkedIn | GitHub | Twitter | Blog
>> >>> >
>> >>> > --
>> >>> > You received this message because you are subscribed to the Google
>> >>> > Groups
>> >>> > "ODK Developers" group.
>> >>> > To unsubscribe from this group and stop receiving emails from it,
>> send
>> >>> > an
>> >>> > email to opendatakit-developers+unsubscribe@googlegroups.com
>> .
>> >>> > For more options, visit https://groups.google.com/d/optout.
>> >>>
>> >>> --
>> >>> You received this message because you are subscribed to the Google
>> Groups
>> >>> "ODK Developers" group.
>> >>> To unsubscribe from this group and stop receiving emails from it,
>> send an
>> >>> email to opendatakit-developers+unsubscribe@googlegroups.com
>> .
>> >>> For more options, visit https://groups.google.com/d/optout.
>> >>
>> >> --
>> >> You received this message because you are subscribed to the Google
>> Groups
>> >> "ODK Developers" group.
>> >> To unsubscribe from this group and stop receiving emails from it, send
>> an
>> >> email to opendatakit-developers+unsubscribe@googlegroups.com
>> .
>> >> For more options, visit https://groups.google.com/d/optout.
>> >
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups
>> > "ODK Developers" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an
>> > email to opendatakit-developers+unsubscribe@googlegroups.com
>> .
>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "ODK Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to opendatakit-developers+unsubscribe@googlegroups.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
I rather like Chris' idea of parentheses at the end of the name. Can
XLSForm and the other tools handle parens?
French (fr)
UK English (en-gb)
With whatever is in the trailing paren being an ISO 639-1 language code.
Note that Java locale and Android res are non-conformant - there are a few
codes that need to be altered from this list.
···
On Fri, Jul 24, 2015 at 9:03 AM, Martijn van de Rijdt wrote:
I neglected to mention we wanted to add support for spaces in languages
names with a single underscore like "pbt__Southern_Pastho" assuming spaces
would be a problem in Pyxform column headings. However, apparently spaces
are fine so that negates the need for a double underscore.
(1) "en-GB_Proper English" and "en_Proper English" syntax seems fine with
me
(2) additional support for just tags such as "pbt" or "en-GB" (and trying
to find a match for the display name) seems fine with me too
(3) and then the existing usage with e.g. "English" where the client can
try to make a match to get the tag (if the client wants to).
The backwards compatibility issue if underscores have been used in
language names in the past won't break forms, just the language display
name in the language selector. Is that acceptable, or do we need a
different separator?
On Friday, July 24, 2015 at 5:48:21 AM UTC-6, Matt Berg wrote:
We might also want to support dialects. So for example:
en-AU_British English
en-US_Freedom English
Anything after the _ is shown to the user (e.g. Freedom English). And
if that description isn't there, clients can pull the language
description from somewhere else.
On Fri, Jul 24, 2015 at 5:58 AM, Matt Berg mlb...@gmail.com wrote:
Agree i don't like the double underscore.
I'd vote for an option if we go this route that we also support just
fr or
en and have ODK/Enketo do the match so we're consistent.
The nice thing about the approach right now is it allows people to make
mistakes and it still works. This is pretty helpful when you are
supporting
weird language dialects
On Fri, Jul 24, 2015 at 1:43 PM, Christopher Robert < cro...@surveycto.com> wrote:
Also seems reasonable to me. And I guess the double underscore makes
it
less likely that we misfire and start hacking off the first part of a
language name that had an _ for other reasons. I'd hate for this to
cause us
a bunch of backward-compatibility support issues.
One idea might be to put the subtag second. We have lots of people who
have devices with old versions of Collect, e.g., even after they've
upgraded
most or all of their other system components. The question is whether
"fr__French" or "French__fr" is the friendlier thing to show in the
language
selector for such cases. And I'd argue that the latter is slightly
more
friendly.
For that matter, the friendliest would be "French (fr)". So
specifying the
subtag in a parenthetical could be another way to go, to be most
friendly
for unsupporting clients.
Seems reasonable to me. Only nit is why a double underscore instead
of a
single?
Yaw
Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.
On Thu, Jul 23, 2015 at 6:49 PM, Martijn van de Rijdt mar...@enketo.org wrote:
Hi ODK devs,
For a project KoBoToolbox is implementing, we ran into a limitation
with
language names. We'd like to propose a slight difference in
recommending
language name usage in XForms/XLSForms. Instead of e.g.
“Français”, we
could
recommend that users start using a two-part string with a “__"
separator
e.g. “fr__Français".
The first part is the valid (2 or 3 character) IANA subtag. The
second
part
is the language name that should be displayed in a language
switcher on
the
client (could be in any spelling variant). So, if ‘ar_العربية‘ is
used,
the
language switcher would just show العربية.
Advantages:
The client's awareness of the actual language code will allow a
future
feature that automatically matches the form language with the
UI/browser/OS
language or vice versa.
It will allow web clients to create valid lang attributes.
“French”
is not
a valid value. “fr” is a valid value.
Old forms won’t break if we would start recommending this. We’d
just,
ideally, have to add some logic to Collect/Enketo/Other clients
that
checks
whether the language name includes ‘__’ and if so, displays only
the
second
part in the language switcher.
Any interest in supporting this or any suggestions for an
alternative
approach?
···
On Friday, July 24, 2015 at 10:20:51 AM UTC-6, Mitch wrote:
>
> I rather like Chris' idea of parentheses at the end of the name. Can
> XLSForm and the other tools handle parens?
>
> French (fr)
> UK English (en-gb)
>
> With whatever is in the trailing paren being an ISO 639-1 language code.
>
> Note that Java locale and Android res are non-conformant - there are a
> few codes that need to be altered from this list.
> http://stackoverflow.com/questions/13974169/jdk-locale-class-handling-of-iso-language-codes-for-hebrew-he-yiddish-yi-an
>
>
> On Fri, Jul 24, 2015 at 9:03 AM, Martijn van de Rijdt <mar...@enketo.org > wrote:
>
>> :)
>>
>> I neglected to mention we wanted to add support for spaces in languages
>> names with a single underscore like "pbt__Southern_Pastho" assuming spaces
>> would be a problem in Pyxform column headings. However, apparently spaces
>> are fine so that negates the need for a double underscore.
>>
>> (1) "en-GB_Proper English" and "en_Proper English" syntax seems fine
>> with me
>> (2) additional support for just tags such as "pbt" or "en-GB" (and trying
>> to find a match for the display name) seems fine with me too
>> (3) and then the existing usage with e.g. "English" where the client can
>> try to make a match to get the tag (if the client wants to).
>>
>> The backwards compatibility issue if underscores have been used in
>> language names in the past won't break forms, just the language display
>> name in the language selector. Is that acceptable, or do we need a
>> different separator?
>>
>> On Friday, July 24, 2015 at 5:48:21 AM UTC-6, Matt Berg wrote:
>>>
>>> en_US-Merica!
>>>
>>>
>>>
>>> On Fri, Jul 24, 2015 at 2:38 PM, Yaw Anokwa wrote:
>>>
>>>> We might also want to support dialects. So for example:
>>>> en-AU_British English
>>>> en-US_Freedom English
>>>>
>>>> Anything after the _ is shown to the user (e.g. Freedom English). And
>>>> if that description isn't there, clients can pull the language
>>>> description from somewhere else.
>>>>
>>>> On Fri, Jul 24, 2015 at 5:58 AM, Matt Berg wrote:
>>>> > Agree i don't like the double underscore.
>>>> >
>>>> > I'd vote for an option if we go this route that we also support just
>>>> fr or
>>>> > en and have ODK/Enketo do the match so we're consistent.
>>>> >
>>>> > The nice thing about the approach right now is it allows people to
>>>> make
>>>> > mistakes and it still works. This is pretty helpful when you are
>>>> supporting
>>>> > weird language dialects
>>>> >
>>>> > On Fri, Jul 24, 2015 at 1:43 PM, Christopher Robert < cro...@surveycto.com> wrote:
>>>> >>
>>>> >> Also seems reasonable to me. And I guess the double underscore makes
>>>> it
>>>> >> less likely that we misfire and start hacking off the first part of a
>>>> >> language name that had an _ for other reasons. I'd hate for this to
>>>> cause us
>>>> >> a bunch of backward-compatibility support issues.
>>>> >>
>>>> >> One idea might be to put the subtag second. We have lots of people
>>>> who
>>>> >> have devices with old versions of Collect, e.g., even after they've
>>>> upgraded
>>>> >> most or all of their other system components. The question is whether
>>>> >> "fr__French" or "French__fr" is the friendlier thing to show in the
>>>> language
>>>> >> selector for such cases. And I'd argue that the latter is slightly
>>>> more
>>>> >> friendly.
>>>> >>
>>>> >> For that matter, the friendliest would be "French (fr)". So
>>>> specifying the
>>>> >> subtag in a parenthetical could be another way to go, to be most
>>>> friendly
>>>> >> for unsupporting clients.
>>>> >>
>>>> >> Best,
>>>> >>
>>>> >> Chris
>>>> >>
>>>> >> ---
>>>> >> Christopher Robert
>>>> >> Dobility, Inc. (SurveyCTO)
>>>> >> http://www.surveycto.com/
>>>> >> http://blog.surveycto.com/
>>>> >>
>>>> >> On Thu, Jul 23, 2015 at 10:34 PM Yaw Anokwa wrote:
>>>> >>>
>>>> >>> Martijn,
>>>> >>>
>>>> >>> Seems reasonable to me. Only nit is why a double underscore instead
>>>> of a
>>>> >>> single?
>>>> >>>
>>>> >>> Yaw
>>>> >>> --
>>>> >>> Need ODK services? http://nafundi.com provides form design, server
>>>> >>> setup, professional support, and software development for ODK.
>>>> >>>
>>>> >>> On Thu, Jul 23, 2015 at 6:49 PM, Martijn van de Rijdt wrote:
>>>> >>> > Hi ODK devs,
>>>> >>> >
>>>> >>> >
>>>> >>> > For a project KoBoToolbox is implementing, we ran into a
>>>> limitation
>>>> >>> > with
>>>> >>> > language names. We'd like to propose a slight difference in
>>>> >>> > recommending
>>>> >>> > language name usage in XForms/XLSForms. Instead of e.g.
>>>> “Français”, we
>>>> >>> > could
>>>> >>> > recommend that users start using a two-part string with a “__"
>>>> >>> > separator
>>>> >>> > e.g. “fr__Français".
>>>> >>> >
>>>> >>> >
>>>> >>> > The first part is the valid (2 or 3 character) IANA subtag. The
>>>> second
>>>> >>> > part
>>>> >>> > is the language name that should be displayed in a language
>>>> switcher on
>>>> >>> > the
>>>> >>> > client (could be in any spelling variant). So, if ‘ar_العربية‘ is
>>>> used,
>>>> >>> > the
>>>> >>> > language switcher would just show العربية.
>>>> >>> >
>>>> >>> >
>>>> >>> > Advantages:
>>>> >>> >
>>>> >>> > The client's awareness of the actual language code will allow a
>>>> future
>>>> >>> > feature that automatically matches the form language with the
>>>> >>> > UI/browser/OS
>>>> >>> > language or vice versa.
>>>> >>> > It will allow web clients to create valid `lang` attributes.
>>>> “French”
>>>> >>> > is not
>>>> >>> > a valid value. “fr” is a valid value.
>>>> >>> >
>>>> >>> > Old forms won’t break if we would start recommending this. We’d
>>>> just,
>>>> >>> > ideally, have to add some logic to Collect/Enketo/Other clients
>>>> that
>>>> >>> > checks
>>>> >>> > whether the language name includes ‘__’ and if so, displays only
>>>> the
>>>> >>> > second
>>>> >>> > part in the language switcher.
>>>> >>> >
>>>> >>> >
>>>> >>> > Any interest in supporting this or any suggestions for an
>>>> alternative
>>>> >>> > approach?
>>>> >>> >
>>>> >>> >
>>>> >>> > Cheers,
>>>> >>> >
>>>> >>> > Martijn
>>>> >>> >
>>>> >>> >
>>>> >>> > --
>>>> >>> > Revolutionizing data collection since 2012.
>>>> >>> >
>>>> >>> > Enketo | LinkedIn | GitHub | Twitter |
>>>> Blog
>>>> >>> >
>>>> >>> > --
>>>> >>> > You received this message because you are subscribed to the Google
>>>> >>> > Groups
>>>> >>> > "ODK Developers" group.
>>>> >>> > To unsubscribe from this group and stop receiving emails from it,
>>>> send
>>>> >>> > an
>>>> >>> > email to opendatakit-developers+unsubscribe@googlegroups.com.
>>>> >>> > For more options, visit https://groups.google.com/d/optout.
>>>> >>>
>>>> >>> --
>>>> >>> You received this message because you are subscribed to the Google
>>>> Groups
>>>> >>> "ODK Developers" group.
>>>> >>> To unsubscribe from this group and stop receiving emails from it,
>>>> send an
>>>> >>> email to opendatakit-developers+unsubscribe@googlegroups.com.
>>>> >>> For more options, visit https://groups.google.com/d/optout.
>>>> >>
>>>> >> --
>>>> >> You received this message because you are subscribed to the Google
>>>> Groups
>>>> >> "ODK Developers" group.
>>>> >> To unsubscribe from this group and stop receiving emails from it,
>>>> send an
>>>> >> email to opendatakit-developers+unsubscribe@googlegroups.com.
>>>> >> For more options, visit https://groups.google.com/d/optout.
>>>> >
>>>> >
>>>> > --
>>>> > You received this message because you are subscribed to the Google
>>>> Groups
>>>> > "ODK Developers" group.
>>>> > To unsubscribe from this group and stop receiving emails from it,
>>>> send an
>>>> > email to opendatakit-developers+unsubscribe@googlegroups.com.
>>>> > For more options, visit https://groups.google.com/d/optout.
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "ODK Developers" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to opendatakit-developers+unsubscribe@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>>
>> --
>> *Revolutionizing data collection since 2012.*
>>
>> Enketo | LinkedIn
>> | GitHub
>> | Twitter
>> | Blog
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "ODK Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to opendatakit-developers+unsubscribe@googlegroups.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Mitch Sundt
> Software Engineer
> University of Washington
> mitche...@gmail.com
>
···
On Friday, July 24, 2015 at 10:30:02 AM UTC-6, Martijn van de Rijdt wrote:
>
> I have no problem with the parentheses syntax either. XLSForm can handle
> this.
>
> I believe IANA subtags
>
> are what is currently recommended (at least for the web). I have no idea if
> they actually differ from ISO 639-1 codes though. Do you have a strong
> preference for ISO 639-1 Mitch? (In case there are differences).
>
>
> On Friday, July 24, 2015 at 10:20:51 AM UTC-6, Mitch wrote:
>>
>> I rather like Chris' idea of parentheses at the end of the name. Can
>> XLSForm and the other tools handle parens?
>>
>> French (fr)
>> UK English (en-gb)
>>
>> With whatever is in the trailing paren being an ISO 639-1 language code.
>>
>> Note that Java locale and Android res are non-conformant - there are a
>> few codes that need to be altered from this list.
>> http://stackoverflow.com/questions/13974169/jdk-locale-class-handling-of-iso-language-codes-for-hebrew-he-yiddish-yi-an
>>
>>
>> On Fri, Jul 24, 2015 at 9:03 AM, Martijn van de Rijdt wrote:
>>
>>> :)
>>>
>>> I neglected to mention we wanted to add support for spaces in languages
>>> names with a single underscore like "pbt__Southern_Pastho" assuming spaces
>>> would be a problem in Pyxform column headings. However, apparently spaces
>>> are fine so that negates the need for a double underscore.
>>>
>>> (1) "en-GB_Proper English" and "en_Proper English" syntax seems fine
>>> with me
>>> (2) additional support for just tags such as "pbt" or "en-GB" (and
>>> trying to find a match for the display name) seems fine with me too
>>> (3) and then the existing usage with e.g. "English" where the client can
>>> try to make a match to get the tag (if the client wants to).
>>>
>>> The backwards compatibility issue if underscores have been used in
>>> language names in the past won't break forms, just the language display
>>> name in the language selector. Is that acceptable, or do we need a
>>> different separator?
>>>
>>> On Friday, July 24, 2015 at 5:48:21 AM UTC-6, Matt Berg wrote:
>>>>
>>>> en_US-Merica!
>>>>
>>>>
>>>>
>>>> On Fri, Jul 24, 2015 at 2:38 PM, Yaw Anokwa wrote:
>>>>
>>>>> We might also want to support dialects. So for example:
>>>>> en-AU_British English
>>>>> en-US_Freedom English
>>>>>
>>>>> Anything after the _ is shown to the user (e.g. Freedom English). And
>>>>> if that description isn't there, clients can pull the language
>>>>> description from somewhere else.
>>>>>
>>>>> On Fri, Jul 24, 2015 at 5:58 AM, Matt Berg wrote:
>>>>> > Agree i don't like the double underscore.
>>>>> >
>>>>> > I'd vote for an option if we go this route that we also support just
>>>>> fr or
>>>>> > en and have ODK/Enketo do the match so we're consistent.
>>>>> >
>>>>> > The nice thing about the approach right now is it allows people to
>>>>> make
>>>>> > mistakes and it still works. This is pretty helpful when you are
>>>>> supporting
>>>>> > weird language dialects
>>>>> >
>>>>> > On Fri, Jul 24, 2015 at 1:43 PM, Christopher Robert < cro...@surveycto.com> wrote:
>>>>> >>
>>>>> >> Also seems reasonable to me. And I guess the double underscore
>>>>> makes it
>>>>> >> less likely that we misfire and start hacking off the first part of
>>>>> a
>>>>> >> language name that had an _ for other reasons. I'd hate for this to
>>>>> cause us
>>>>> >> a bunch of backward-compatibility support issues.
>>>>> >>
>>>>> >> One idea might be to put the subtag second. We have lots of people
>>>>> who
>>>>> >> have devices with old versions of Collect, e.g., even after they've
>>>>> upgraded
>>>>> >> most or all of their other system components. The question is
>>>>> whether
>>>>> >> "fr__French" or "French__fr" is the friendlier thing to show in the
>>>>> language
>>>>> >> selector for such cases. And I'd argue that the latter is slightly
>>>>> more
>>>>> >> friendly.
>>>>> >>
>>>>> >> For that matter, the friendliest would be "French (fr)". So
>>>>> specifying the
>>>>> >> subtag in a parenthetical could be another way to go, to be most
>>>>> friendly
>>>>> >> for unsupporting clients.
>>>>> >>
>>>>> >> Best,
>>>>> >>
>>>>> >> Chris
>>>>> >>
>>>>> >> ---
>>>>> >> Christopher Robert
>>>>> >> Dobility, Inc. (SurveyCTO)
>>>>> >> http://www.surveycto.com/
>>>>> >> http://blog.surveycto.com/
>>>>> >>
>>>>> >> On Thu, Jul 23, 2015 at 10:34 PM Yaw Anokwa wrote:
>>>>> >>>
>>>>> >>> Martijn,
>>>>> >>>
>>>>> >>> Seems reasonable to me. Only nit is why a double underscore
>>>>> instead of a
>>>>> >>> single?
>>>>> >>>
>>>>> >>> Yaw
>>>>> >>> --
>>>>> >>> Need ODK services? http://nafundi.com provides form design, server
>>>>> >>> setup, professional support, and software development for ODK.
>>>>> >>>
>>>>> >>> On Thu, Jul 23, 2015 at 6:49 PM, Martijn van de Rijdt wrote:
>>>>> >>> > Hi ODK devs,
>>>>> >>> >
>>>>> >>> >
>>>>> >>> > For a project KoBoToolbox is implementing, we ran into a
>>>>> limitation
>>>>> >>> > with
>>>>> >>> > language names. We'd like to propose a slight difference in
>>>>> >>> > recommending
>>>>> >>> > language name usage in XForms/XLSForms. Instead of e.g.
>>>>> “Français”, we
>>>>> >>> > could
>>>>> >>> > recommend that users start using a two-part string with a “__"
>>>>> >>> > separator
>>>>> >>> > e.g. “fr__Français".
>>>>> >>> >
>>>>> >>> >
>>>>> >>> > The first part is the valid (2 or 3 character) IANA subtag. The
>>>>> second
>>>>> >>> > part
>>>>> >>> > is the language name that should be displayed in a language
>>>>> switcher on
>>>>> >>> > the
>>>>> >>> > client (could be in any spelling variant). So, if ‘ar_العربية‘
>>>>> is used,
>>>>> >>> > the
>>>>> >>> > language switcher would just show العربية.
>>>>> >>> >
>>>>> >>> >
>>>>> >>> > Advantages:
>>>>> >>> >
>>>>> >>> > The client's awareness of the actual language code will allow a
>>>>> future
>>>>> >>> > feature that automatically matches the form language with the
>>>>> >>> > UI/browser/OS
>>>>> >>> > language or vice versa.
>>>>> >>> > It will allow web clients to create valid `lang` attributes.
>>>>> “French”
>>>>> >>> > is not
>>>>> >>> > a valid value. “fr” is a valid value.
>>>>> >>> >
>>>>> >>> > Old forms won’t break if we would start recommending this. We’d
>>>>> just,
>>>>> >>> > ideally, have to add some logic to Collect/Enketo/Other clients
>>>>> that
>>>>> >>> > checks
>>>>> >>> > whether the language name includes ‘__’ and if so, displays only
>>>>> the
>>>>> >>> > second
>>>>> >>> > part in the language switcher.
>>>>> >>> >
>>>>> >>> >
>>>>> >>> > Any interest in supporting this or any suggestions for an
>>>>> alternative
>>>>> >>> > approach?
>>>>> >>> >
>>>>> >>> >
>>>>> >>> > Cheers,
>>>>> >>> >
>>>>> >>> > Martijn
>>>>> >>> >
>>>>> >>> >
>>>>> >>> > --
>>>>> >>> > Revolutionizing data collection since 2012.
>>>>> >>> >
>>>>> >>> > Enketo | LinkedIn | GitHub | Twitter |
>>>>> Blog
>>>>> >>> >
>>>>> >>> > --
>>>>> >>> > You received this message because you are subscribed to the
>>>>> Google
>>>>> >>> > Groups
>>>>> >>> > "ODK Developers" group.
>>>>> >>> > To unsubscribe from this group and stop receiving emails from
>>>>> it, send
>>>>> >>> > an
>>>>> >>> > email to opendatakit-developers+unsubscribe@googlegroups.com.
>>>>> >>> > For more options, visit https://groups.google.com/d/optout.
>>>>> >>>
>>>>> >>> --
>>>>> >>> You received this message because you are subscribed to the Google
>>>>> Groups
>>>>> >>> "ODK Developers" group.
>>>>> >>> To unsubscribe from this group and stop receiving emails from it,
>>>>> send an
>>>>> >>> email to opendatakit-developers+unsubscribe@googlegroups.com.
>>>>> >>> For more options, visit https://groups.google.com/d/optout.
>>>>> >>
>>>>> >> --
>>>>> >> You received this message because you are subscribed to the Google
>>>>> Groups
>>>>> >> "ODK Developers" group.
>>>>> >> To unsubscribe from this group and stop receiving emails from it,
>>>>> send an
>>>>> >> email to opendatakit-developers+unsubscribe@googlegroups.com.
>>>>> >> For more options, visit https://groups.google.com/d/optout.
>>>>> >
>>>>> >
>>>>> > --
>>>>> > You received this message because you are subscribed to the Google
>>>>> Groups
>>>>> > "ODK Developers" group.
>>>>> > To unsubscribe from this group and stop receiving emails from it,
>>>>> send an
>>>>> > email to opendatakit-developers+unsubscribe@googlegroups.com.
>>>>> > For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "ODK Developers" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to opendatakit-developers+unsubscribe@googlegroups.com.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>
>>>>
>>> --
>>> *Revolutionizing data collection since 2012.*
>>>
>>> Enketo | LinkedIn
>>> | GitHub
>>> | Twitter
>>> | Blog
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "ODK Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to opendatakit-developers+unsubscribe@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Mitch Sundt
>> Software Engineer
>> University of Washington
>> mitche...@gmail.com
>>
>
We try outrageously hard to avoid breaking anything for existing forms when
our users upgrade. And if we do break something, we can look forward to
dozens or even hundreds of support tickets over the course of time. So we'd
be far more likely to institute a change if it doesn't break existing
forms. (That said, I honestly don't know how many people might be using _'s
now. If, like you, people assumed that spaces weren't allowed, then many
might have used _'s.)
Chris
···
On Fri, Jul 24, 2015 at 12:03 PM Martijn van de Rijdt wrote:
I neglected to mention we wanted to add support for spaces in languages
names with a single underscore like "pbt__Southern_Pastho" assuming spaces
would be a problem in Pyxform column headings. However, apparently spaces
are fine so that negates the need for a double underscore.
(1) "en-GB_Proper English" and "en_Proper English" syntax seems fine with
me
(2) additional support for just tags such as "pbt" or "en-GB" (and trying
to find a match for the display name) seems fine with me too
(3) and then the existing usage with e.g. "English" where the client can
try to make a match to get the tag (if the client wants to).
The backwards compatibility issue if underscores have been used in
language names in the past won't break forms, just the language display
name in the language selector. Is that acceptable, or do we need a
different separator?
On Friday, July 24, 2015 at 5:48:21 AM UTC-6, Matt Berg wrote:
We might also want to support dialects. So for example:
en-AU_British English
en-US_Freedom English
Anything after the _ is shown to the user (e.g. Freedom English). And
if that description isn't there, clients can pull the language
description from somewhere else.
On Fri, Jul 24, 2015 at 5:58 AM, Matt Berg mlb...@gmail.com wrote:
Agree i don't like the double underscore.
I'd vote for an option if we go this route that we also support just
fr or
en and have ODK/Enketo do the match so we're consistent.
The nice thing about the approach right now is it allows people to make
mistakes and it still works. This is pretty helpful when you are
supporting
weird language dialects
On Fri, Jul 24, 2015 at 1:43 PM, Christopher Robert < cro...@surveycto.com> wrote:
Also seems reasonable to me. And I guess the double underscore makes
it
less likely that we misfire and start hacking off the first part of a
language name that had an _ for other reasons. I'd hate for this to
cause us
a bunch of backward-compatibility support issues.
One idea might be to put the subtag second. We have lots of people who
have devices with old versions of Collect, e.g., even after they've
upgraded
most or all of their other system components. The question is whether
"fr__French" or "French__fr" is the friendlier thing to show in the
language
selector for such cases. And I'd argue that the latter is slightly
more
friendly.
For that matter, the friendliest would be "French (fr)". So
specifying the
subtag in a parenthetical could be another way to go, to be most
friendly
for unsupporting clients.
Seems reasonable to me. Only nit is why a double underscore instead
of a
single?
Yaw
Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.
On Thu, Jul 23, 2015 at 6:49 PM, Martijn van de Rijdt mar...@enketo.org wrote:
Hi ODK devs,
For a project KoBoToolbox is implementing, we ran into a limitation
with
language names. We'd like to propose a slight difference in
recommending
language name usage in XForms/XLSForms. Instead of e.g.
“Français”, we
could
recommend that users start using a two-part string with a “__"
separator
e.g. “fr__Français".
The first part is the valid (2 or 3 character) IANA subtag. The
second
part
is the language name that should be displayed in a language
switcher on
the
client (could be in any spelling variant). So, if ‘ar_العربية‘ is
used,
the
language switcher would just show العربية.
Advantages:
The client's awareness of the actual language code will allow a
future
feature that automatically matches the form language with the
UI/browser/OS
language or vice versa.
It will allow web clients to create valid lang attributes.
“French”
is not
a valid value. “fr” is a valid value.
Old forms won’t break if we would start recommending this. We’d
just,
ideally, have to add some logic to Collect/Enketo/Other clients
that
checks
whether the language name includes ‘__’ and if so, displays only
the
second
part in the language switcher.
Any interest in supporting this or any suggestions for an
alternative
approach?
Cheers,
Martijn
--
Revolutionizing data collection since 2012.
Enketo | LinkedIn | GitHub | Twitter | Blog
--
You received this message because you are subscribed to the Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send
an
--
You received this message because you are subscribed to the Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send an
--
You received this message because you are subscribed to the Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send an
--
You received this message because you are subscribed to the Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an
If we used parens, I would argue that we might not even have to trim it
from, e.g., the Collect app. "U.S. English (en-us)" isn't really offensive
or obviously broken in any way. But others might feel differently about
that.
Chris
···
On Fri, Jul 24, 2015 at 12:30 PM Martijn van de Rijdt wrote:
I have no problem with the parentheses syntax either. XLSForm can handle
this.
On Fri, Jul 24, 2015 at 9:03 AM, Martijn van de Rijdt mar...@enketo.org wrote:
I neglected to mention we wanted to add support for spaces in languages
names with a single underscore like "pbt__Southern_Pastho" assuming spaces
would be a problem in Pyxform column headings. However, apparently spaces
are fine so that negates the need for a double underscore.
(1) "en-GB_Proper English" and "en_Proper English" syntax seems fine
with me
(2) additional support for just tags such as "pbt" or "en-GB" (and
trying to find a match for the display name) seems fine with me too
(3) and then the existing usage with e.g. "English" where the client can
try to make a match to get the tag (if the client wants to).
The backwards compatibility issue if underscores have been used in
language names in the past won't break forms, just the language display
name in the language selector. Is that acceptable, or do we need a
different separator?
On Friday, July 24, 2015 at 5:48:21 AM UTC-6, Matt Berg wrote:
We might also want to support dialects. So for example:
en-AU_British English
en-US_Freedom English
Anything after the _ is shown to the user (e.g. Freedom English). And
if that description isn't there, clients can pull the language
description from somewhere else.
On Fri, Jul 24, 2015 at 5:58 AM, Matt Berg mlb...@gmail.com wrote:
Agree i don't like the double underscore.
I'd vote for an option if we go this route that we also support just
fr or
en and have ODK/Enketo do the match so we're consistent.
The nice thing about the approach right now is it allows people to
make
mistakes and it still works. This is pretty helpful when you are
supporting
weird language dialects
On Fri, Jul 24, 2015 at 1:43 PM, Christopher Robert < cro...@surveycto.com> wrote:
Also seems reasonable to me. And I guess the double underscore
makes it
less likely that we misfire and start hacking off the first part of
a
language name that had an _ for other reasons. I'd hate for this to
cause us
a bunch of backward-compatibility support issues.
One idea might be to put the subtag second. We have lots of people
who
have devices with old versions of Collect, e.g., even after they've
upgraded
most or all of their other system components. The question is
whether
"fr__French" or "French__fr" is the friendlier thing to show in the
language
selector for such cases. And I'd argue that the latter is slightly
more
friendly.
For that matter, the friendliest would be "French (fr)". So
specifying the
subtag in a parenthetical could be another way to go, to be most
friendly
for unsupporting clients.
Seems reasonable to me. Only nit is why a double underscore
instead of a
single?
Yaw
Need ODK services? http://nafundi.com provides form design, server
setup, professional support, and software development for ODK.
On Thu, Jul 23, 2015 at 6:49 PM, Martijn van de Rijdt mar...@enketo.org wrote:
Hi ODK devs,
For a project KoBoToolbox is implementing, we ran into a
limitation
with
language names. We'd like to propose a slight difference in
recommending
language name usage in XForms/XLSForms. Instead of e.g.
“Français”, we
could
recommend that users start using a two-part string with a “__"
separator
e.g. “fr__Français".
The first part is the valid (2 or 3 character) IANA subtag. The
second
part
is the language name that should be displayed in a language
switcher on
the
client (could be in any spelling variant). So, if ‘ar_العربية‘
is used,
the
language switcher would just show العربية.
Advantages:
The client's awareness of the actual language code will allow a
future
feature that automatically matches the form language with the
UI/browser/OS
language or vice versa.
It will allow web clients to create valid lang attributes.
“French”
is not
a valid value. “fr” is a valid value.
Old forms won’t break if we would start recommending this. We’d
just,
ideally, have to add some logic to Collect/Enketo/Other clients
that
checks
whether the language name includes ‘__’ and if so, displays only
the
second
part in the language switcher.
Any interest in supporting this or any suggestions for an
alternative
approach?
Sure, lets go with that. Thinking about this, there isn't any code change
required on ODK Collect. This is just for web-based processing, so it makes
sense to go with the w3c IANA list.
···
----------------
Or is there something that would need to change in the Java client?
If we used parens, I would argue that we might not even have to trim it
from, e.g., the Collect app. "U.S. English (en-us)" isn't really offensive
or obviously broken in any way. But others might feel differently about
that.
Chris
On Fri, Jul 24, 2015 at 12:30 PM Martijn van de Rijdt martijn@enketo.org wrote:
I have no problem with the parentheses syntax either. XLSForm can handle
this.
On Fri, Jul 24, 2015 at 9:03 AM, Martijn van de Rijdt <mar...@enketo.org wrote:
I neglected to mention we wanted to add support for spaces in languages
names with a single underscore like "pbt__Southern_Pastho" assuming spaces
would be a problem in Pyxform column headings. However, apparently spaces
are fine so that negates the need for a double underscore.
(1) "en-GB_Proper English" and "en_Proper English" syntax seems fine
with me
(2) additional support for just tags such as "pbt" or "en-GB" (and
trying to find a match for the display name) seems fine with me too
(3) and then the existing usage with e.g. "English" where the client
can try to make a match to get the tag (if the client wants to).
The backwards compatibility issue if underscores have been used in
language names in the past won't break forms, just the language display
name in the language selector. Is that acceptable, or do we need a
different separator?
On Friday, July 24, 2015 at 5:48:21 AM UTC-6, Matt Berg wrote:
We might also want to support dialects. So for example:
en-AU_British English
en-US_Freedom English
Anything after the _ is shown to the user (e.g. Freedom English). And
if that description isn't there, clients can pull the language
description from somewhere else.
On Fri, Jul 24, 2015 at 5:58 AM, Matt Berg mlb...@gmail.com wrote:
Agree i don't like the double underscore.
I'd vote for an option if we go this route that we also support
just fr or
en and have ODK/Enketo do the match so we're consistent.
The nice thing about the approach right now is it allows people to
make
mistakes and it still works. This is pretty helpful when you are
supporting
weird language dialects
On Fri, Jul 24, 2015 at 1:43 PM, Christopher Robert < cro...@surveycto.com> wrote:
Also seems reasonable to me. And I guess the double underscore
makes it
less likely that we misfire and start hacking off the first part
of a
language name that had an _ for other reasons. I'd hate for this
to cause us
a bunch of backward-compatibility support issues.
One idea might be to put the subtag second. We have lots of people
who
have devices with old versions of Collect, e.g., even after
they've upgraded
most or all of their other system components. The question is
whether
"fr__French" or "French__fr" is the friendlier thing to show in
the language
selector for such cases. And I'd argue that the latter is slightly
more
friendly.
For that matter, the friendliest would be "French (fr)". So
specifying the
subtag in a parenthetical could be another way to go, to be most
friendly
for unsupporting clients.
Seems reasonable to me. Only nit is why a double underscore
instead of a
single?
Yaw
Need ODK services? http://nafundi.com provides form design,
server
setup, professional support, and software development for ODK.
On Thu, Jul 23, 2015 at 6:49 PM, Martijn van de Rijdt mar...@enketo.org wrote:
Hi ODK devs,
For a project KoBoToolbox is implementing, we ran into a
limitation
with
language names. We'd like to propose a slight difference in
recommending
language name usage in XForms/XLSForms. Instead of e.g.
“Français”, we
could
recommend that users start using a two-part string with a “__"
separator
e.g. “fr__Français".
The first part is the valid (2 or 3 character) IANA subtag. The
second
part
is the language name that should be displayed in a language
switcher on
the
client (could be in any spelling variant). So, if ‘ar_العربية‘
is used,
the
language switcher would just show العربية.
Advantages:
The client's awareness of the actual language code will allow a
future
feature that automatically matches the form language with the
UI/browser/OS
language or vice versa.
It will allow web clients to create valid lang attributes.
“French”
is not
a valid value. “fr” is a valid value.
Old forms won’t break if we would start recommending this. We’d
just,
ideally, have to add some logic to Collect/Enketo/Other clients
that
checks
whether the language name includes ‘__’ and if so, displays
only the
second
part in the language switcher.
Any interest in supporting this or any suggestions for an
alternative
approach?
The only required change would be if we wanted to also support just the
subtag "en" to do a lookup of the language name. But I think with the
parentheses syntax it doesn't seem very logical to support that usage.
···
On Friday, July 24, 2015 at 10:48:42 AM UTC-6, Mitch wrote:
>
> Re: just leaving () at the end
>
> That works for me!
>
> Re: IANA
>
> Sure, lets go with that. Thinking about this, there isn't any code change
> required on ODK Collect. This is just for web-based processing, so it makes
> sense to go with the w3c IANA list.
>
> ----------------
> Or is there something that would need to change in the Java client?
>
>
> On Fri, Jul 24, 2015 at 9:36 AM, Christopher Robert <cro...@surveycto.com > wrote:
>
>> If we used parens, I would argue that we might not even have to trim it
>> from, e.g., the Collect app. "U.S. English (en-us)" isn't really offensive
>> or obviously broken in any way. But others might feel differently about
>> that.
>>
>> Chris
>>
>> On Fri, Jul 24, 2015 at 12:30 PM Martijn van de Rijdt <mar...@enketo.org > wrote:
>>
>>> I have no problem with the parentheses syntax either. XLSForm can handle
>>> this.
>>>
>>> I believe IANA subtags
>>>
>>> are what is currently recommended (at least for the web). I have no idea if
>>> they actually differ from ISO 639-1 codes though. Do you have a strong
>>> preference for ISO 639-1 Mitch? (In case there are differences).
>>>
>>>
>>> On Friday, July 24, 2015 at 10:20:51 AM UTC-6, Mitch wrote:
>>>
>>>> I rather like Chris' idea of parentheses at the end of the name. Can
>>>> XLSForm and the other tools handle parens?
>>>>
>>>> French (fr)
>>>> UK English (en-gb)
>>>>
>>>> With whatever is in the trailing paren being an ISO 639-1 language
>>>> code.
>>>>
>>>> Note that Java locale and Android res are non-conformant - there are a
>>>> few codes that need to be altered from this list.
>>>> http://stackoverflow.com/questions/13974169/jdk-locale-class-handling-of-iso-language-codes-for-hebrew-he-yiddish-yi-an
>>>>
>>>> On Fri, Jul 24, 2015 at 9:03 AM, Martijn van de Rijdt < mar...@enketo.org> wrote:
>>>>
>>> :)
>>>>>
>>>>> I neglected to mention we wanted to add support for spaces in
>>>>> languages names with a single underscore like "pbt__Southern_Pastho"
>>>>> assuming spaces would be a problem in Pyxform column headings. However,
>>>>> apparently spaces are fine so that negates the need for a double underscore.
>>>>>
>>>>> (1) "en-GB_Proper English" and "en_Proper English" syntax seems fine
>>>>> with me
>>>>> (2) additional support for just tags such as "pbt" or "en-GB" (and
>>>>> trying to find a match for the display name) seems fine with me too
>>>>> (3) and then the existing usage with e.g. "English" where the client
>>>>> can try to make a match to get the tag (if the client wants to).
>>>>>
>>>>> The backwards compatibility issue if underscores have been used in
>>>>> language names in the past won't break forms, just the language display
>>>>> name in the language selector. Is that acceptable, or do we need a
>>>>> different separator?
>>>>>
>>>>> On Friday, July 24, 2015 at 5:48:21 AM UTC-6, Matt Berg wrote:
>>>>>>
>>>>>> en_US-Merica!
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Jul 24, 2015 at 2:38 PM, Yaw Anokwa wrote:
>>>>>>
>>>>>>> We might also want to support dialects. So for example:
>>>>>>> en-AU_British English
>>>>>>> en-US_Freedom English
>>>>>>>
>>>>>>> Anything after the _ is shown to the user (e.g. Freedom English).
>>>>>>> And
>>>>>>> if that description isn't there, clients can pull the language
>>>>>>> description from somewhere else.
>>>>>>>
>>>>>>> On Fri, Jul 24, 2015 at 5:58 AM, Matt Berg wrote:
>>>>>>> > Agree i don't like the double underscore.
>>>>>>> >
>>>>>>> > I'd vote for an option if we go this route that we also support
>>>>>>> just fr or
>>>>>>> > en and have ODK/Enketo do the match so we're consistent.
>>>>>>> >
>>>>>>> > The nice thing about the approach right now is it allows people to
>>>>>>> make
>>>>>>> > mistakes and it still works. This is pretty helpful when you are
>>>>>>> supporting
>>>>>>> > weird language dialects
>>>>>>> >
>>>>>>> > On Fri, Jul 24, 2015 at 1:43 PM, Christopher Robert < cro...@surveycto.com> wrote:
>>>>>>> >>
>>>>>>> >> Also seems reasonable to me. And I guess the double underscore
>>>>>>> makes it
>>>>>>> >> less likely that we misfire and start hacking off the first part
>>>>>>> of a
>>>>>>> >> language name that had an _ for other reasons. I'd hate for this
>>>>>>> to cause us
>>>>>>> >> a bunch of backward-compatibility support issues.
>>>>>>> >>
>>>>>>> >> One idea might be to put the subtag second. We have lots of
>>>>>>> people who
>>>>>>> >> have devices with old versions of Collect, e.g., even after
>>>>>>> they've upgraded
>>>>>>> >> most or all of their other system components. The question is
>>>>>>> whether
>>>>>>> >> "fr__French" or "French__fr" is the friendlier thing to show in
>>>>>>> the language
>>>>>>> >> selector for such cases. And I'd argue that the latter is
>>>>>>> slightly more
>>>>>>> >> friendly.
>>>>>>> >>
>>>>>>> >> For that matter, the friendliest would be "French (fr)". So
>>>>>>> specifying the
>>>>>>> >> subtag in a parenthetical could be another way to go, to be most
>>>>>>> friendly
>>>>>>> >> for unsupporting clients.
>>>>>>> >>
>>>>>>> >> Best,
>>>>>>> >>
>>>>>>> >> Chris
>>>>>>> >>
>>>>>>> >> ---
>>>>>>> >> Christopher Robert
>>>>>>> >> Dobility, Inc. (SurveyCTO)
>>>>>>> >> http://www.surveycto.com/
>>>>>>> >> http://blog.surveycto.com/
>>>>>>> >>
>>>>>>> >> On Thu, Jul 23, 2015 at 10:34 PM Yaw Anokwa wrote:
>>>>>>> >>>
>>>>>>> >>> Martijn,
>>>>>>> >>>
>>>>>>> >>> Seems reasonable to me. Only nit is why a double underscore
>>>>>>> instead of a
>>>>>>> >>> single?
>>>>>>> >>>
>>>>>>> >>> Yaw
>>>>>>> >>> --
>>>>>>> >>> Need ODK services? http://nafundi.com provides form design,
>>>>>>> server
>>>>>>> >>> setup, professional support, and software development for ODK.
>>>>>>> >>>
>>>>>>> >>> On Thu, Jul 23, 2015 at 6:49 PM, Martijn van de Rijdt wrote:
>>>>>>> >>> > Hi ODK devs,
>>>>>>> >>> >
>>>>>>> >>> >
>>>>>>> >>> > For a project KoBoToolbox is implementing, we ran into a
>>>>>>> limitation
>>>>>>> >>> > with
>>>>>>> >>> > language names. We'd like to propose a slight difference in
>>>>>>> >>> > recommending
>>>>>>> >>> > language name usage in XForms/XLSForms. Instead of e.g.
>>>>>>> “Français”, we
>>>>>>> >>> > could
>>>>>>> >>> > recommend that users start using a two-part string with a “__"
>>>>>>> >>> > separator
>>>>>>> >>> > e.g. “fr__Français".
>>>>>>> >>> >
>>>>>>> >>> >
>>>>>>> >>> > The first part is the valid (2 or 3 character) IANA subtag.
>>>>>>> The second
>>>>>>> >>> > part
>>>>>>> >>> > is the language name that should be displayed in a language
>>>>>>> switcher on
>>>>>>> >>> > the
>>>>>>> >>> > client (could be in any spelling variant). So, if ‘ar_العربية‘
>>>>>>> is used,
>>>>>>> >>> > the
>>>>>>> >>> > language switcher would just show العربية.
>>>>>>> >>> >
>>>>>>> >>> >
>>>>>>> >>> > Advantages:
>>>>>>> >>> >
>>>>>>> >>> > The client's awareness of the actual language code will allow
>>>>>>> a future
>>>>>>> >>> > feature that automatically matches the form language with the
>>>>>>> >>> > UI/browser/OS
>>>>>>> >>> > language or vice versa.
>>>>>>> >>> > It will allow web clients to create valid `lang` attributes.
>>>>>>> “French”
>>>>>>> >>> > is not
>>>>>>> >>> > a valid value. “fr” is a valid value.
>>>>>>> >>> >
>>>>>>> >>> > Old forms won’t break if we would start recommending this.
>>>>>>> We’d just,
>>>>>>> >>> > ideally, have to add some logic to Collect/Enketo/Other
>>>>>>> clients that
>>>>>>> >>> > checks
>>>>>>> >>> > whether the language name includes ‘__’ and if so, displays
>>>>>>> only the
>>>>>>> >>> > second
>>>>>>> >>> > part in the language switcher.
>>>>>>> >>> >
>>>>>>> >>> >
>>>>>>> >>> > Any interest in supporting this or any suggestions for an
>>>>>>> alternative
>>>>>>> >>> > approach?
>>>>>>> >>> >
>>>>>>> >>> >
>>>>>>> >>> > Cheers,
>>>>>>> >>> >
>>>>>>> >>> > Martijn
>>>>>>> >>> >
>>>>>>> >>> >
>>>>>>> >>> > --
>>>>>>> >>> > Revolutionizing data collection since 2012.
>>>>>>> >>> >
>>>>>>> >>> > Enketo | LinkedIn | GitHub | Twitter |
>>>>>>> Blog
>>>>>>> >>> >
>>>>>>> >>> > --
>>>>>>> >>> > You received this message because you are subscribed to the
>>>>>>> Google
>>>>>>> >>> > Groups
>>>>>>> >>> > "ODK Developers" group.
>>>>>>> >>> > To unsubscribe from this group and stop receiving emails from
>>>>>>> it, send
>>>>>>> >>> > an
>>>>>>> >>> > email to opendatakit-developers+unsubscribe@googlegroups.com.
>>>>>>> >>> > For more options, visit https://groups.google.com/d/optout.
>>>>>>> >>>
>>>>>>> >>> --
>>>>>>> >>> You received this message because you are subscribed to the
>>>>>>> Google Groups
>>>>>>> >>> "ODK Developers" group.
>>>>>>> >>> To unsubscribe from this group and stop receiving emails from
>>>>>>> it, send an
>>>>>>> >>> email to opendatakit-developers+unsubscribe@googlegroups.com.
>>>>>>> >>> For more options, visit https://groups.google.com/d/optout.
>>>>>>> >>
>>>>>>> >> --
>>>>>>> >> You received this message because you are subscribed to the
>>>>>>> Google Groups
>>>>>>> >> "ODK Developers" group.
>>>>>>> >> To unsubscribe from this group and stop receiving emails from it,
>>>>>>> send an
>>>>>>> >> email to opendatakit-developers+unsubscribe@googlegroups.com.
>>>>>>> >> For more options, visit https://groups.google.com/d/optout.
>>>>>>> >
>>>>>>> >
>>>>>>> > --
>>>>>>> > You received this message because you are subscribed to the Google
>>>>>>> Groups
>>>>>>> > "ODK Developers" group.
>>>>>>> > To unsubscribe from this group and stop receiving emails from it,
>>>>>>> send an
>>>>>>> > email to opendatakit-developers+unsubscribe@googlegroups.com.
>>>>>>> > For more options, visit https://groups.google.com/d/optout.
>>>>>>>
>>>>>>> --
>>>>>>> You received this message because you are subscribed to the Google
>>>>>>> Groups "ODK Developers" group.
>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>> send an email to opendatakit-developers+unsubscribe@googlegroups.com
>>>>>>> .
>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>
>>>>>>
>>>>>>
>>>>> --
>>>>> *Revolutionizing data collection since 2012.*
>>>>>
>>>>> Enketo | LinkedIn
>>>>> | GitHub
>>>>> | Twitter
>>>>> | Blog
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "ODK Developers" group.
>>>>>
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to opendatakit-developers+unsubscribe@googlegroups.com.
>>>>>
>>>>
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>> Mitch Sundt
>>>> Software Engineer
>>>> University of Washington
>>>>
>>> mitche...@gmail.com
>>>>
>>>
>>> --
>>> *Revolutionizing data collection since 2012.*
>>>
>>> Enketo | LinkedIn
>>> | GitHub
>>> | Twitter
>>> | Blog
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "ODK Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to opendatakit-developers+unsubscribe@googlegroups.com
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>
>
> --
> Mitch Sundt
> Software Engineer
> University of Washington
> mitche...@gmail.com
>
I would prefer hiding the language identifier at the data entry stage.
"پشتو" looks better than "پشتو (ps)" to most users.
As far as I can tell ISO 639-1 is included entirely within IANA, so this
could still be used for other purposes. One of which might be setting the
interface language depending on the form language (probably easier for
Enketo than for Collect).
Tino
···
On Fri, Jul 24, 2015 at 12:48 PM, Mitch Sundt wrote:
Re: just leaving () at the end
That works for me!
Re: IANA
Sure, lets go with that. Thinking about this, there isn't any code change
required on ODK Collect. This is just for web-based processing, so it makes
sense to go with the w3c IANA list.
Or is there something that would need to change in the Java client?
If we used parens, I would argue that we might not even have to trim it
from, e.g., the Collect app. "U.S. English (en-us)" isn't really offensive
or obviously broken in any way. But others might feel differently about
that.
Chris
On Fri, Jul 24, 2015 at 12:30 PM Martijn van de Rijdt martijn@enketo.org wrote:
I have no problem with the parentheses syntax either. XLSForm can handle
this.
On Fri, Jul 24, 2015 at 9:03 AM, Martijn van de Rijdt < mar...@enketo.org> wrote:
I neglected to mention we wanted to add support for spaces in
languages names with a single underscore like "pbt__Southern_Pastho"
assuming spaces would be a problem in Pyxform column headings. However,
apparently spaces are fine so that negates the need for a double underscore.
(1) "en-GB_Proper English" and "en_Proper English" syntax seems fine
with me
(2) additional support for just tags such as "pbt" or "en-GB" (and
trying to find a match for the display name) seems fine with me too
(3) and then the existing usage with e.g. "English" where the client
can try to make a match to get the tag (if the client wants to).
The backwards compatibility issue if underscores have been used in
language names in the past won't break forms, just the language display
name in the language selector. Is that acceptable, or do we need a
different separator?
On Friday, July 24, 2015 at 5:48:21 AM UTC-6, Matt Berg wrote:
We might also want to support dialects. So for example:
en-AU_British English
en-US_Freedom English
Anything after the _ is shown to the user (e.g. Freedom English).
And
if that description isn't there, clients can pull the language
description from somewhere else.
On Fri, Jul 24, 2015 at 5:58 AM, Matt Berg mlb...@gmail.com wrote:
Agree i don't like the double underscore.
I'd vote for an option if we go this route that we also support
just fr or
en and have ODK/Enketo do the match so we're consistent.
The nice thing about the approach right now is it allows people to
make
mistakes and it still works. This is pretty helpful when you are
supporting
weird language dialects
On Fri, Jul 24, 2015 at 1:43 PM, Christopher Robert < cro...@surveycto.com> wrote:
Also seems reasonable to me. And I guess the double underscore
makes it
less likely that we misfire and start hacking off the first part
of a
language name that had an _ for other reasons. I'd hate for this
to cause us
a bunch of backward-compatibility support issues.
One idea might be to put the subtag second. We have lots of
people who
have devices with old versions of Collect, e.g., even after
they've upgraded
most or all of their other system components. The question is
whether
"fr__French" or "French__fr" is the friendlier thing to show in
the language
selector for such cases. And I'd argue that the latter is
slightly more
friendly.
For that matter, the friendliest would be "French (fr)". So
specifying the
subtag in a parenthetical could be another way to go, to be most
friendly
for unsupporting clients.
Seems reasonable to me. Only nit is why a double underscore
instead of a
single?
Yaw
Need ODK services? http://nafundi.com provides form design,
server
setup, professional support, and software development for ODK.
On Thu, Jul 23, 2015 at 6:49 PM, Martijn van de Rijdt mar...@enketo.org wrote:
Hi ODK devs,
For a project KoBoToolbox is implementing, we ran into a
limitation
with
language names. We'd like to propose a slight difference in
recommending
language name usage in XForms/XLSForms. Instead of e.g.
“Français”, we
could
recommend that users start using a two-part string with a “__"
separator
e.g. “fr__Français".
The first part is the valid (2 or 3 character) IANA subtag.
The second
part
is the language name that should be displayed in a language
switcher on
the
client (could be in any spelling variant). So, if ‘ar_العربية‘
is used,
the
language switcher would just show العربية.
Advantages:
The client's awareness of the actual language code will allow
a future
feature that automatically matches the form language with the
UI/browser/OS
language or vice versa.
It will allow web clients to create valid lang attributes.
“French”
is not
a valid value. “fr” is a valid value.
Old forms won’t break if we would start recommending this.
We’d just,
ideally, have to add some logic to Collect/Enketo/Other
clients that
checks
whether the language name includes ‘__’ and if so, displays
only the
second
part in the language switcher.
Any interest in supporting this or any suggestions for an
alternative
approach?
···
On Friday, July 24, 2015 at 11:08:56 AM UTC-6, Martijn van de Rijdt wrote:
>
> The only required change would be if we wanted to also support just the
> subtag "en" to do a lookup of the language name. But I think with the
> parentheses syntax it doesn't seem very logical to support that usage.
>
> On Friday, July 24, 2015 at 10:48:42 AM UTC-6, Mitch wrote:
>>
>> Re: just leaving () at the end
>>
>> That works for me!
>>
>> Re: IANA
>>
>> Sure, lets go with that. Thinking about this, there isn't any code change
>> required on ODK Collect. This is just for web-based processing, so it makes
>> sense to go with the w3c IANA list.
>>
>> ----------------
>> Or is there something that would need to change in the Java client?
>>
>>
>> On Fri, Jul 24, 2015 at 9:36 AM, Christopher Robert >
>>> If we used parens, I would argue that we might not even have to trim it
>>> from, e.g., the Collect app. "U.S. English (en-us)" isn't really offensive
>>> or obviously broken in any way. But others might feel differently about
>>> that.
>>>
>>> Chris
>>>
>>> On Fri, Jul 24, 2015 at 12:30 PM Martijn van de Rijdt wrote:
>>>
>>>> I have no problem with the parentheses syntax either. XLSForm can
>>>> handle this.
>>>>
>>>> I believe IANA subtags
>>>>
>>>> are what is currently recommended (at least for the web). I have no idea if
>>>> they actually differ from ISO 639-1 codes though. Do you have a strong
>>>> preference for ISO 639-1 Mitch? (In case there are differences).
>>>>
>>>>
>>>> On Friday, July 24, 2015 at 10:20:51 AM UTC-6, Mitch wrote:
>>>>
>>>>> I rather like Chris' idea of parentheses at the end of the name. Can
>>>>> XLSForm and the other tools handle parens?
>>>>>
>>>>> French (fr)
>>>>> UK English (en-gb)
>>>>>
>>>>> With whatever is in the trailing paren being an ISO 639-1 language
>>>>> code.
>>>>>
>>>>> Note that Java locale and Android res are non-conformant - there are
>>>>> a few codes that need to be altered from this list.
>>>>> http://stackoverflow.com/questions/13974169/jdk-locale-class-handling-of-iso-language-codes-for-hebrew-he-yiddish-yi-an
>>>>>
>>>>> On Fri, Jul 24, 2015 at 9:03 AM, Martijn van de Rijdt < mar...@enketo.org> wrote:
>>>>>
>>>> :)
>>>>>>
>>>>>> I neglected to mention we wanted to add support for spaces in
>>>>>> languages names with a single underscore like "pbt__Southern_Pastho"
>>>>>> assuming spaces would be a problem in Pyxform column headings. However,
>>>>>> apparently spaces are fine so that negates the need for a double underscore.
>>>>>>
>>>>>> (1) "en-GB_Proper English" and "en_Proper English" syntax seems fine
>>>>>> with me
>>>>>> (2) additional support for just tags such as "pbt" or "en-GB" (and
>>>>>> trying to find a match for the display name) seems fine with me too
>>>>>> (3) and then the existing usage with e.g. "English" where the client
>>>>>> can try to make a match to get the tag (if the client wants to).
>>>>>>
>>>>>> The backwards compatibility issue if underscores have been used in
>>>>>> language names in the past won't break forms, just the language display
>>>>>> name in the language selector. Is that acceptable, or do we need a
>>>>>> different separator?
>>>>>>
>>>>>> On Friday, July 24, 2015 at 5:48:21 AM UTC-6, Matt Berg wrote:
>>>>>>>
>>>>>>> en_US-Merica!
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Jul 24, 2015 at 2:38 PM, Yaw Anokwa wrote:
>>>>>>>
>>>>>>>> We might also want to support dialects. So for example:
>>>>>>>> en-AU_British English
>>>>>>>> en-US_Freedom English
>>>>>>>>
>>>>>>>> Anything after the _ is shown to the user (e.g. Freedom English).
>>>>>>>> And
>>>>>>>> if that description isn't there, clients can pull the language
>>>>>>>> description from somewhere else.
>>>>>>>>
>>>>>>>> On Fri, Jul 24, 2015 at 5:58 AM, Matt Berg wrote:
>>>>>>>> > Agree i don't like the double underscore.
>>>>>>>> >
>>>>>>>> > I'd vote for an option if we go this route that we also support
>>>>>>>> just fr or
>>>>>>>> > en and have ODK/Enketo do the match so we're consistent.
>>>>>>>> >
>>>>>>>> > The nice thing about the approach right now is it allows people
>>>>>>>> to make
>>>>>>>> > mistakes and it still works. This is pretty helpful when you are
>>>>>>>> supporting
>>>>>>>> > weird language dialects
>>>>>>>> >
>>>>>>>> > On Fri, Jul 24, 2015 at 1:43 PM, Christopher Robert < cro...@surveycto.com> wrote:
>>>>>>>> >>
>>>>>>>> >> Also seems reasonable to me. And I guess the double underscore
>>>>>>>> makes it
>>>>>>>> >> less likely that we misfire and start hacking off the first part
>>>>>>>> of a
>>>>>>>> >> language name that had an _ for other reasons. I'd hate for this
>>>>>>>> to cause us
>>>>>>>> >> a bunch of backward-compatibility support issues.
>>>>>>>> >>
>>>>>>>> >> One idea might be to put the subtag second. We have lots of
>>>>>>>> people who
>>>>>>>> >> have devices with old versions of Collect, e.g., even after
>>>>>>>> they've upgraded
>>>>>>>> >> most or all of their other system components. The question is
>>>>>>>> whether
>>>>>>>> >> "fr__French" or "French__fr" is the friendlier thing to show in
>>>>>>>> the language
>>>>>>>> >> selector for such cases. And I'd argue that the latter is
>>>>>>>> slightly more
>>>>>>>> >> friendly.
>>>>>>>> >>
>>>>>>>> >> For that matter, the friendliest would be "French (fr)". So
>>>>>>>> specifying the
>>>>>>>> >> subtag in a parenthetical could be another way to go, to be most
>>>>>>>> friendly
>>>>>>>> >> for unsupporting clients.
>>>>>>>> >>
>>>>>>>> >> Best,
>>>>>>>> >>
>>>>>>>> >> Chris
>>>>>>>> >>
>>>>>>>> >> ---
>>>>>>>> >> Christopher Robert
>>>>>>>> >> Dobility, Inc. (SurveyCTO)
>>>>>>>> >> http://www.surveycto.com/
>>>>>>>> >> http://blog.surveycto.com/
>>>>>>>> >>
>>>>>>>> >> On Thu, Jul 23, 2015 at 10:34 PM Yaw Anokwa wrote:
>>>>>>>> >>>
>>>>>>>> >>> Martijn,
>>>>>>>> >>>
>>>>>>>> >>> Seems reasonable to me. Only nit is why a double underscore
>>>>>>>> instead of a
>>>>>>>> >>> single?
>>>>>>>> >>>
>>>>>>>> >>> Yaw
>>>>>>>> >>> --
>>>>>>>> >>> Need ODK services? http://nafundi.com provides form design,
>>>>>>>> server
>>>>>>>> >>> setup, professional support, and software development for ODK.
>>>>>>>> >>>
>>>>>>>> >>> On Thu, Jul 23, 2015 at 6:49 PM, Martijn van de Rijdt wrote:
>>>>>>>> >>> > Hi ODK devs,
>>>>>>>> >>> >
>>>>>>>> >>> >
>>>>>>>> >>> > For a project KoBoToolbox is implementing, we ran into a
>>>>>>>> limitation
>>>>>>>> >>> > with
>>>>>>>> >>> > language names. We'd like to propose a slight difference in
>>>>>>>> >>> > recommending
>>>>>>>> >>> > language name usage in XForms/XLSForms. Instead of e.g.
>>>>>>>> “Français”, we
>>>>>>>> >>> > could
>>>>>>>> >>> > recommend that users start using a two-part string with a “__"
>>>>>>>> >>> > separator
>>>>>>>> >>> > e.g. “fr__Français".
>>>>>>>> >>> >
>>>>>>>> >>> >
>>>>>>>> >>> > The first part is the valid (2 or 3 character) IANA subtag.
>>>>>>>> The second
>>>>>>>> >>> > part
>>>>>>>> >>> > is the language name that should be displayed in a language
>>>>>>>> switcher on
>>>>>>>> >>> > the
>>>>>>>> >>> > client (could be in any spelling variant). So, if
>>>>>>>> ‘ar_العربية‘ is used,
>>>>>>>> >>> > the
>>>>>>>> >>> > language switcher would just show العربية.
>>>>>>>> >>> >
>>>>>>>> >>> >
>>>>>>>> >>> > Advantages:
>>>>>>>> >>> >
>>>>>>>> >>> > The client's awareness of the actual language code will allow
>>>>>>>> a future
>>>>>>>> >>> > feature that automatically matches the form language with the
>>>>>>>> >>> > UI/browser/OS
>>>>>>>> >>> > language or vice versa.
>>>>>>>> >>> > It will allow web clients to create valid `lang` attributes.
>>>>>>>> “French”
>>>>>>>> >>> > is not
>>>>>>>> >>> > a valid value. “fr” is a valid value.
>>>>>>>> >>> >
>>>>>>>> >>> > Old forms won’t break if we would start recommending this.
>>>>>>>> We’d just,
>>>>>>>> >>> > ideally, have to add some logic to Collect/Enketo/Other
>>>>>>>> clients that
>>>>>>>> >>> > checks
>>>>>>>> >>> > whether the language name includes ‘__’ and if so, displays
>>>>>>>> only the
>>>>>>>> >>> > second
>>>>>>>> >>> > part in the language switcher.
>>>>>>>> >>> >
>>>>>>>> >>> >
>>>>>>>> >>> > Any interest in supporting this or any suggestions for an
>>>>>>>> alternative
>>>>>>>> >>> > approach?
>>>>>>>> >>> >
>>>>>>>> >>> >
>>>>>>>> >>> > Cheers,
>>>>>>>> >>> >
>>>>>>>> >>> > Martijn
>>>>>>>> >>> >
>>>>>>>> >>> >
>>>>>>>> >>> > --
>>>>>>>> >>> > Revolutionizing data collection since 2012.
>>>>>>>> >>> >
>>>>>>>> >>> > Enketo | LinkedIn | GitHub | Twitter |
>>>>>>>> Blog
>>>>>>>> >>> >
>>>>>>>> >>> > --
>>>>>>>> >>> > You received this message because you are subscribed to the
>>>>>>>> Google
>>>>>>>> >>> > Groups
>>>>>>>> >>> > "ODK Developers" group.
>>>>>>>> >>> > To unsubscribe from this group and stop receiving emails from
>>>>>>>> it, send
>>>>>>>> >>> > an
>>>>>>>> >>> > email to opendatakit-developers+unsubscribe@googlegroups.com.
>>>>>>>> >>> > For more options, visit https://groups.google.com/d/optout.
>>>>>>>> >>>
>>>>>>>> >>> --
>>>>>>>> >>> You received this message because you are subscribed to the
>>>>>>>> Google Groups
>>>>>>>> >>> "ODK Developers" group.
>>>>>>>> >>> To unsubscribe from this group and stop receiving emails from
>>>>>>>> it, send an
>>>>>>>> >>> email to opendatakit-developers+unsubscribe@googlegroups.com.
>>>>>>>> >>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>> >>
>>>>>>>> >> --
>>>>>>>> >> You received this message because you are subscribed to the
>>>>>>>> Google Groups
>>>>>>>> >> "ODK Developers" group.
>>>>>>>> >> To unsubscribe from this group and stop receiving emails from
>>>>>>>> it, send an
>>>>>>>> >> email to opendatakit-developers+unsubscribe@googlegroups.com.
>>>>>>>> >> For more options, visit https://groups.google.com/d/optout.
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > --
>>>>>>>> > You received this message because you are subscribed to the
>>>>>>>> Google Groups
>>>>>>>> > "ODK Developers" group.
>>>>>>>> > To unsubscribe from this group and stop receiving emails from it,
>>>>>>>> send an
>>>>>>>> > email to opendatakit-developers+unsubscribe@googlegroups.com.
>>>>>>>> > For more options, visit https://groups.google.com/d/optout.
>>>>>>>>
>>>>>>>> --
>>>>>>>> You received this message because you are subscribed to the Google
>>>>>>>> Groups "ODK Developers" group.
>>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>>> send an email to
>>>>>>>> opendatakit-developers+unsubscribe@googlegroups.com.
>>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> *Revolutionizing data collection since 2012.*
>>>>>>
>>>>>> Enketo | LinkedIn
>>>>>> | GitHub
>>>>>> | Twitter
>>>>>> | Blog
>>>>>>
>>>>>> --
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "ODK Developers" group.
>>>>>>
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>>> an email to opendatakit-developers+unsubscribe@googlegroups.com.
>>>>>>
>>>>>
>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>> Mitch Sundt
>>>>> Software Engineer
>>>>> University of Washington
>>>>>
>>>> mitche...@gmail.com
>>>>>
>>>>
>>>> --
>>>> *Revolutionizing data collection since 2012.*
>>>>
>>>> Enketo | LinkedIn
>>>> | GitHub
>>>> | Twitter
>>>> | Blog
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "ODK Developers" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to opendatakit-developers+unsubscribe@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>
>>
>> --
>> Mitch Sundt
>> Software Engineer
>> University of Washington
>> mitche...@gmail.com
>>
>
···
On Mon, Jul 27, 2015 at 10:21 AM, Martijn van de Rijdt wrote:
> Yaw, Matt, are you okay with the paren syntax?
>
> On Friday, July 24, 2015 at 11:08:56 AM UTC-6, Martijn van de Rijdt wrote:
>>
>> The only required change would be if we wanted to also support just the
>> subtag "en" to do a lookup of the language name. But I think with the
>> parentheses syntax it doesn't seem very logical to support that usage.
>>
>> On Friday, July 24, 2015 at 10:48:42 AM UTC-6, Mitch wrote:
>>>
>>> Re: just leaving () at the end
>>>
>>> That works for me!
>>>
>>> Re: IANA
>>>
>>> Sure, lets go with that. Thinking about this, there isn't any code change
>>> required on ODK Collect. This is just for web-based processing, so it makes
>>> sense to go with the w3c IANA list.
>>>
>>> ----------------
>>> Or is there something that would need to change in the Java client?
>>>
>>>
>>> On Fri, Jul 24, 2015 at 9:36 AM, Christopher Robert wrote:
>>>>
>>>> If we used parens, I would argue that we might not even have to trim it
>>>> from, e.g., the Collect app. "U.S. English (en-us)" isn't really offensive
>>>> or obviously broken in any way. But others might feel differently about
>>>> that.
>>>>
>>>> Chris
>>>>
>>>> On Fri, Jul 24, 2015 at 12:30 PM Martijn van de Rijdt wrote:
>>>>>
>>>>> I have no problem with the parentheses syntax either. XLSForm can
>>>>> handle this.
>>>>>
>>>>> I believe IANA subtags are what is currently recommended (at least for
>>>>> the web). I have no idea if they actually differ from ISO 639-1 codes
>>>>> though. Do you have a strong preference for ISO 639-1 Mitch? (In case there
>>>>> are differences).
>>>>>
>>>>>
>>>>> On Friday, July 24, 2015 at 10:20:51 AM UTC-6, Mitch wrote:
>>>>>>
>>>>>> I rather like Chris' idea of parentheses at the end of the name. Can
>>>>>> XLSForm and the other tools handle parens?
>>>>>>
>>>>>> French (fr)
>>>>>> UK English (en-gb)
>>>>>>
>>>>>> With whatever is in the trailing paren being an ISO 639-1 language
>>>>>> code.
>>>>>>
>>>>>> Note that Java locale and Android res are non-conformant - there are
>>>>>> a few codes that need to be altered from this list.
>>>>>> http://stackoverflow.com/questions/13974169/jdk-locale-class-handling-of-iso-language-codes-for-hebrew-he-yiddish-yi-an
>>>>>>
>>>>>> On Fri, Jul 24, 2015 at 9:03 AM, Martijn van de Rijdt wrote:
>>>>>>>
>>>>>>> :)
>>>>>>>
>>>>>>> I neglected to mention we wanted to add support for spaces in
>>>>>>> languages names with a single underscore like "pbt__Southern_Pastho"
>>>>>>> assuming spaces would be a problem in Pyxform column headings. However,
>>>>>>> apparently spaces are fine so that negates the need for a double underscore.
>>>>>>>
>>>>>>> (1) "en-GB_Proper English" and "en_Proper English" syntax seems fine
>>>>>>> with me
>>>>>>> (2) additional support for just tags such as "pbt" or "en-GB" (and
>>>>>>> trying to find a match for the display name) seems fine with me too
>>>>>>> (3) and then the existing usage with e.g. "English" where the client
>>>>>>> can try to make a match to get the tag (if the client wants to).
>>>>>>>
>>>>>>> The backwards compatibility issue if underscores have been used in
>>>>>>> language names in the past won't break forms, just the language display name
>>>>>>> in the language selector. Is that acceptable, or do we need a different
>>>>>>> separator?
>>>>>>>
>>>>>>> On Friday, July 24, 2015 at 5:48:21 AM UTC-6, Matt Berg wrote:
>>>>>>>>
>>>>>>>> en_US-Merica!
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Jul 24, 2015 at 2:38 PM, Yaw Anokwa wrote:
>>>>>>>>>
>>>>>>>>> We might also want to support dialects. So for example:
>>>>>>>>> en-AU_British English
>>>>>>>>> en-US_Freedom English
>>>>>>>>>
>>>>>>>>> Anything after the _ is shown to the user (e.g. Freedom English).
>>>>>>>>> And
>>>>>>>>> if that description isn't there, clients can pull the language
>>>>>>>>> description from somewhere else.
>>>>>>>>>
>>>>>>>>> On Fri, Jul 24, 2015 at 5:58 AM, Matt Berg wrote:
>>>>>>>>> > Agree i don't like the double underscore.
>>>>>>>>> >
>>>>>>>>> > I'd vote for an option if we go this route that we also support
>>>>>>>>> > just fr or
>>>>>>>>> > en and have ODK/Enketo do the match so we're consistent.
>>>>>>>>> >
>>>>>>>>> > The nice thing about the approach right now is it allows people
>>>>>>>>> > to make
>>>>>>>>> > mistakes and it still works. This is pretty helpful when you are
>>>>>>>>> > supporting
>>>>>>>>> > weird language dialects
>>>>>>>>> >
>>>>>>>>> > On Fri, Jul 24, 2015 at 1:43 PM, Christopher Robert wrote:
>>>>>>>>> >>
>>>>>>>>> >> Also seems reasonable to me. And I guess the double underscore
>>>>>>>>> >> makes it
>>>>>>>>> >> less likely that we misfire and start hacking off the first part
>>>>>>>>> >> of a
>>>>>>>>> >> language name that had an _ for other reasons. I'd hate for this
>>>>>>>>> >> to cause us
>>>>>>>>> >> a bunch of backward-compatibility support issues.
>>>>>>>>> >>
>>>>>>>>> >> One idea might be to put the subtag second. We have lots of
>>>>>>>>> >> people who
>>>>>>>>> >> have devices with old versions of Collect, e.g., even after
>>>>>>>>> >> they've upgraded
>>>>>>>>> >> most or all of their other system components. The question is
>>>>>>>>> >> whether
>>>>>>>>> >> "fr__French" or "French__fr" is the friendlier thing to show in
>>>>>>>>> >> the language
>>>>>>>>> >> selector for such cases. And I'd argue that the latter is
>>>>>>>>> >> slightly more
>>>>>>>>> >> friendly.
>>>>>>>>> >>
>>>>>>>>> >> For that matter, the friendliest would be "French (fr)". So
>>>>>>>>> >> specifying the
>>>>>>>>> >> subtag in a parenthetical could be another way to go, to be most
>>>>>>>>> >> friendly
>>>>>>>>> >> for unsupporting clients.
>>>>>>>>> >>
>>>>>>>>> >> Best,
>>>>>>>>> >>
>>>>>>>>> >> Chris
>>>>>>>>> >>
>>>>>>>>> >> ---
>>>>>>>>> >> Christopher Robert
>>>>>>>>> >> Dobility, Inc. (SurveyCTO)
>>>>>>>>> >> http://www.surveycto.com/
>>>>>>>>> >> http://blog.surveycto.com/
>>>>>>>>> >>
>>>>>>>>> >> On Thu, Jul 23, 2015 at 10:34 PM Yaw Anokwa wrote:
>>>>>>>>> >>>
>>>>>>>>> >>> Martijn,
>>>>>>>>> >>>
>>>>>>>>> >>> Seems reasonable to me. Only nit is why a double underscore
>>>>>>>>> >>> instead of a
>>>>>>>>> >>> single?
>>>>>>>>> >>>
>>>>>>>>> >>> Yaw
>>>>>>>>> >>> --
>>>>>>>>> >>> Need ODK services? http://nafundi.com provides form design,
>>>>>>>>> >>> server
>>>>>>>>> >>> setup, professional support, and software development for ODK.
>>>>>>>>> >>>
>>>>>>>>> >>> On Thu, Jul 23, 2015 at 6:49 PM, Martijn van de Rijdt wrote:
>>>>>>>>> >>> > Hi ODK devs,
>>>>>>>>> >>> >
>>>>>>>>> >>> >
>>>>>>>>> >>> > For a project KoBoToolbox is implementing, we ran into a
>>>>>>>>> >>> > limitation
>>>>>>>>> >>> > with
>>>>>>>>> >>> > language names. We'd like to propose a slight difference in
>>>>>>>>> >>> > recommending
>>>>>>>>> >>> > language name usage in XForms/XLSForms. Instead of e.g.
>>>>>>>>> >>> > “Français”, we
>>>>>>>>> >>> > could
>>>>>>>>> >>> > recommend that users start using a two-part string with a
>>>>>>>>> >>> > “__"
>>>>>>>>> >>> > separator
>>>>>>>>> >>> > e.g. “fr__Français".
>>>>>>>>> >>> >
>>>>>>>>> >>> >
>>>>>>>>> >>> > The first part is the valid (2 or 3 character) IANA subtag.
>>>>>>>>> >>> > The second
>>>>>>>>> >>> > part
>>>>>>>>> >>> > is the language name that should be displayed in a language
>>>>>>>>> >>> > switcher on
>>>>>>>>> >>> > the
>>>>>>>>> >>> > client (could be in any spelling variant). So, if
>>>>>>>>> >>> > ‘ar_العربية‘ is used,
>>>>>>>>> >>> > the
>>>>>>>>> >>> > language switcher would just show العربية.
>>>>>>>>> >>> >
>>>>>>>>> >>> >
>>>>>>>>> >>> > Advantages:
>>>>>>>>> >>> >
>>>>>>>>> >>> > The client's awareness of the actual language code will allow
>>>>>>>>> >>> > a future
>>>>>>>>> >>> > feature that automatically matches the form language with the
>>>>>>>>> >>> > UI/browser/OS
>>>>>>>>> >>> > language or vice versa.
>>>>>>>>> >>> > It will allow web clients to create valid `lang` attributes.
>>>>>>>>> >>> > “French”
>>>>>>>>> >>> > is not
>>>>>>>>> >>> > a valid value. “fr” is a valid value.
>>>>>>>>> >>> >
>>>>>>>>> >>> > Old forms won’t break if we would start recommending this.
>>>>>>>>> >>> > We’d just,
>>>>>>>>> >>> > ideally, have to add some logic to Collect/Enketo/Other
>>>>>>>>> >>> > clients that
>>>>>>>>> >>> > checks
>>>>>>>>> >>> > whether the language name includes ‘__’ and if so, displays
>>>>>>>>> >>> > only the
>>>>>>>>> >>> > second
>>>>>>>>> >>> > part in the language switcher.
>>>>>>>>> >>> >
>>>>>>>>> >>> >
>>>>>>>>> >>> > Any interest in supporting this or any suggestions for an
>>>>>>>>> >>> > alternative
>>>>>>>>> >>> > approach?
>>>>>>>>> >>> >
>>>>>>>>> >>> >
>>>>>>>>> >>> > Cheers,
>>>>>>>>> >>> >
>>>>>>>>> >>> > Martijn
>>>>>>>>> >>> >
>>>>>>>>> >>> >
>>>>>>>>> >>> > --
>>>>>>>>> >>> > Revolutionizing data collection since 2012.
>>>>>>>>> >>> >
>>>>>>>>> >>> > Enketo | LinkedIn | GitHub | Twitter |
>>>>>>>>> >>> > Blog
>>>>>>>>> >>> >
>>>>>>>>> >>> > --
>>>>>>>>> >>> > You received this message because you are subscribed to the
>>>>>>>>> >>> > Google
>>>>>>>>> >>> > Groups
>>>>>>>>> >>> > "ODK Developers" group.
>>>>>>>>> >>> > To unsubscribe from this group and stop receiving emails from
>>>>>>>>> >>> > it, send
>>>>>>>>> >>> > an
>>>>>>>>> >>> > email to opendatakit-developers+unsubscribe@googlegroups.com.
>>>>>>>>> >>> > For more options, visit https://groups.google.com/d/optout.
>>>>>>>>> >>>
>>>>>>>>> >>> --
>>>>>>>>> >>> You received this message because you are subscribed to the
>>>>>>>>> >>> Google Groups
>>>>>>>>> >>> "ODK Developers" group.
>>>>>>>>> >>> To unsubscribe from this group and stop receiving emails from
>>>>>>>>> >>> it, send an
>>>>>>>>> >>> email to opendatakit-developers+unsubscribe@googlegroups.com.
>>>>>>>>> >>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>>> >>
>>>>>>>>> >> --
>>>>>>>>> >> You received this message because you are subscribed to the
>>>>>>>>> >> Google Groups
>>>>>>>>> >> "ODK Developers" group.
>>>>>>>>> >> To unsubscribe from this group and stop receiving emails from
>>>>>>>>> >> it, send an
>>>>>>>>> >> email to opendatakit-developers+unsubscribe@googlegroups.com.
>>>>>>>>> >> For more options, visit https://groups.google.com/d/optout.
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > --
>>>>>>>>> > You received this message because you are subscribed to the
>>>>>>>>> > Google Groups
>>>>>>>>> > "ODK Developers" group.
>>>>>>>>> > To unsubscribe from this group and stop receiving emails from it,
>>>>>>>>> > send an
>>>>>>>>> > email to opendatakit-developers+unsubscribe@googlegroups.com.
>>>>>>>>> > For more options, visit https://groups.google.com/d/optout.
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> You received this message because you are subscribed to the Google
>>>>>>>>> Groups "ODK Developers" group.
>>>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>>>> send an email to opendatakit-developers+unsubscribe@googlegroups.com.
>>>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Revolutionizing data collection since 2012.
>>>>>>>
>>>>>>> Enketo | LinkedIn | GitHub | Twitter | Blog
>>>>>>>
>>>>>>> --
>>>>>>> You received this message because you are subscribed to the Google
>>>>>>> Groups "ODK Developers" group.
>>>>>>>
>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>> send an email to opendatakit-developers+unsubscribe@googlegroups.com.
>>>>>>>
>>>>>>>
>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Mitch Sundt
>>>>>> Software Engineer
>>>>>> University of Washington
>>>>>>
>>>>>> mitche...@gmail.com
>>>>>
>>>>>
>>>>> --
>>>>> Revolutionizing data collection since 2012.
>>>>>
>>>>> Enketo | LinkedIn | GitHub | Twitter | Blog
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "ODK Developers" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to opendatakit-developers+unsubscribe@googlegroups.com.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>>
>>>
>>> --
>>> Mitch Sundt
>>> Software Engineer
>>> University of Washington
>>> mitche...@gmail.com
>
>
> --
> Revolutionizing data collection since 2012.
>
> Enketo | LinkedIn | GitHub | Twitter | Blog
>
> --
> You received this message because you are subscribed to the Google Groups
> "ODK Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to opendatakit-developers+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
