Hi,
In Lithuanian language plural forms does not always solves the problem,
because we need more that 2 word ending. AFAIK, the same problem is for
Polish translations. I guess we can live without plurals.
This is resolved in gettext. At least for European languages.
Usually it's possible to define some limited number of basic
rules which depends on given number. F.e. in Polish there are
3 forms: for 1, for numbers ending with 2,3,4 except 11,12,...,19
and for rest.
1 dom
2 domy, 3 domy, 4 domy, 22 domy, 34 domy
5 domów, 6 domów, 11 domów, 13 domów, 31 domów, 45 domów
In Lithuanian you have also 3 forms:
1. for numbers ending with 10, 11, 12, 13, ..., 19
2. for numbers ending with 1
3. for rest
I remembered the problem. I wanted to create app with Lithuanian source
code language, but ngettext() is adopted for english source code.
Do you mean just an overloading of i18n C function by other module, or some
more complex possibility to have alternative gettext?
I'm thinking about simple table with function address which can be
overloaded using some public function so it will be possible to
replace our default functions by user ones.
This can put some restrictions on Harbour's i18n implementation. We will
have to be more GNU gettext compatible and could be more difficult to
gave a different meaning of context or domains, etc. But if you'll find
a solution for both Harbour's i18n and original getetxt, it would be great.
I know about it and I agree that it's not strictly necessary but
I do not know if people who do not use latin base languages will
share this opinion.
If translation tables are not used
cI := i18n_gettext("some text")
is equivalent to
cI := "some text"
So, I don't think we must to input strings. Or... it should be a more
general codepage solution for all strings of Harbour source.
In our own implementation we can define different meaning for domain
then the one which exists in gettext where inside each domain you
have translations for different languages.
In gettext each domain has translations for different libraries (not
languages). (I guess you meant this, but it's just a typing error)
When someone decide to
use our own i18n implementation then usually need it only for his own
application and does not need domains defined like for gettext.
We can also use domains for context translations.
It's our choice.
It would be great, if we can do this way. We support domains and it's
programmers choice use it for libraries or contexts. The only problem to
be solved is how to store domains. In original implementation domain
translations are in different files, but translation for all contexts
are in the same file. We will need to implement one more level in
translation tables. Something like:
{"LANGUAGE"=>"PL_PL", "CPID"=>"PLISO",
"TABLE"=>{""/*no domain*/=>{...}, "DOMAIN1"=>{...}, ...}}
And we can use domain as context signature for alternative translations.
In such case when domain is given we will look for translation in given
domain and if it's not found then in main domain.
To resolve context problem we can also define some dummy pattern which
will be eliminated by our own hb_strFormat() function and use it to create
unique strings, f.e.:
"[EMAIL PROTECTED]"
"[EMAIL PROTECTED]"
%<n>@ will be replaced by empty string.
Yes. I'm currently using a similar solution, but it's a little hackish
and that's why I do not like it a lot.
Best regards,
Mindaugas
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
