Further to Chris Burrell's reply...
BabelPad's Convert Menu for Chinese includes options to convert Simplified
to Traditional & vice versa.
In July 2011, I experimented with this, and did comparisons for the diatheke
dumps from our two Chinese modules.
Details available on request.
The important
My (little) understanding of the Chinese language is that there is a
many-to-1 relationship between Traditional characters and Simplified
characters. (For STEP we used a open-source conversion tool to
automatically convert the translations. Then let our users proof-read the
automatically generated
Nic,
As far as our Chinese modules go, I think it was the case that the source
file for ChiUn (Traditional) was converted from the source file used for the
ChiUns (Simplified). Hmmm!
There's a story behind this that maybe ought to be the subject of a new
thread.
I'm not an expert on Chinese, but
On 4 Jan 2014, at 10:08 am, Chris Little wrote:
> The relevant standard is BCP 47: https://tools.ietf.org/html/bcp47
>
> The standard separator is hyphen (-), but use of underscore is common. POSIX
> locales, for example, use underscore. I guess hyphen should be preferred, but
> we should acc
How the Chinese currently is is acceptable. There are only 2 options and
neither is the default. True, more people in the world use simplified, as that
is the official script of mainland China. But any text that is in Chinese will
specify exactly which script (between the 2) to use. Any that d
As you will see from sword-svn I have created the missing parent files
etc.
I left Chinese alone as I am a bit lost with that.
Peter
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instruct
On 1/3/2014 2:03 PM, DM Smith wrote:
Troy,
Chris has documented that the locale mechanism should look for 3 things:
language, optional country and optional script. The code as it stands works for
any two, treating script as country (I didn't look but assume that country can
take a 4 character
Troy,
Chris has documented that the locale mechanism should look for 3 things:
language, optional country and optional script. The code as it stands works for
any two, treating script as country (I didn't look but assume that country can
take a 4 character script.).
The standard (I read it at o
Thanks Troy,
Both for bug-fix and for the advice. I will see what I can do wrt
creation of adequate parents where these are needed.
On Fri, 2014-01-03 at 12:16 -0700, Troy A. Griffitts wrote:
> Remember, we have MANY MORE language modules than we have locales for
> the engine. Wycliffe alone ha
On Jan 3, 2014, at 2:52 PM, Matej Cepl wrote:
> On Fri, Jan 03, 2014 at 10:54:03AM -0500, DM Smith wrote:
>> Several places I've run into the need to have a designation beyond lang:
>> Portuguese (Portugal vs Brazil), Chinese (Traditional vs Simplified) and
>> Arabic (Egypt vs ???). In the case
On Fri, Jan 03, 2014 at 10:54:03AM -0500, DM Smith wrote:
Several places I've run into the need to have a designation
beyond lang: Portuguese (Portugal vs Brazil), Chinese
(Traditional vs Simplified) and Arabic (Egypt vs ???). In the
case of Chinese it is a script difference, but the others are
Hi guys,
Let me clear up 2 things, and suggest a third.
1) SWORD does have fallback locale logic:
http://crosswire.org/svn/sword/trunk/src/mgr/localemgr.cpp
(search for setDefaultLocaleName)
The problem is here:
if (!getLocale(tmplang)) {
// then continue to search for a fallback
}
getLoca
On Jan 3, 2014, at 11:37 AM, Peter von Kaehne wrote:
>> On Fri, 2014-01-03 at 10:54 -0500, DM Smith wrote:
>> BTW, I like how Java searches for localized resource files. The actual
>> implementation is rather complex (because it searches multiple
>> locations), but to simplify:
>> Given a langua
> On Fri, 2014-01-03 at 10:54 -0500, DM Smith wrote:
> BTW, I like how Java searches for localized resource files. The actual
> implementation is rather complex (because it searches multiple
> locations), but to simplify:
> Given a language code, a country code and a script code (script is new
> to
I think your suggestion makes sense. It is how we do it in JSword.
Several places I've run into the need to have a designation beyond lang:
Portuguese (Portugal vs Brazil), Chinese (Traditional vs Simplified) and Arabic
(Egypt vs ???). In the case of Chinese it is a script difference, but the
o
Would there be any objection if I do following:
1) Many of the description lines of our locale files have the language
name in long form with an added "(Unicode)"
e.g. ru_RU-utf8 reads as follows:
[Meta]
Name=ru_RU
Description=Russian (Unicode)
I see no good reason that the "(Unicode)" is there
16 matches
Mail list logo
