https://bugzilla.wikimedia.org/show_bug.cgi?id=19190





--- Comment #10 from Purodha Blissenbach <bugzilla.wikime...@publi.purodha.net> 
 2009-06-17 07:09:06 UTC ---
(In reply to comment #5)
> To address Roan comments: 
> In the case PLURAL: we probably have to modify the way that is calculated on
> the server via having a array representation ie( array('1-4':X, '5':Y,
> '6-11':Z) (instead of having a php function with switch statements) then we 
> can
> package that array into the JS and replace accordingly.... We should probably
> never mixed code with content translation representation .. This needs to be
> fixed for this case and other that will arise in the future.

The approach sounds pretty reasonable for me.
It could be implemented as a single pre-parse call that is executed on messages
before they
are downloaded to the JS package, be it as a bundle, be it individually.

Currently, we have SITENAME, PLURAL, GENDER, and GRAMMAR in general, and if
Wikis individualize their messages,
arbitrary parser functions. Leaving the latter aside for now, this would be a
workable approach:

{{SITENAME}} - replaced by pre-parse.
{{GRAMMAR with {{SITENAME}} }} - evaluated and replaced by pre-parse.
{{GRAMMAR with other constant }} - evaluated and replaced by pre-parse.
{{GRAMMAR with something variable }} - open, but is it used anywhere?

{{GENDER}} 
currently handled by a case list of individual named constants.
Evaluation is based on user names, whose gender is being looked up whenever a
message is being rendered. 
It needs adding special individial cases for few languages anyways, which
simply means having more than 3 choices. Addition of "polite forms" of
addressing (such as differentiating between youth, standard, and respected old
age, e.g.) has been suggested for languages having that.

Can most easily be switched to enumerate constants via pre-parse.
Implementing an array approach was a snap, if usernames, which currently are
passed as parameters, could be repaced by something like 
index(gender(username))). See below.

{{PLURAL}} 
Plural often does not treat fractions well at the moment, but it works with
integers and it works for 0.0
There are several individual implementations, usually with either a simple
expression, or a compound of ones in a series of "if"s. Imho, the evaluation of
plural could be split into to steps:
1. call a function that returns an index,
2. lookup of the final result via this index.
A general function returning an index imho could be implementd both in php and
JS.
It would work through an array of arithmetic expressions having 1 parameter,
returning the index of the 1st giving a non-zero, or true result; at the end of
the array return one more.
The function would be fed with the value to check, and an array like ( 0: " x
!= 1 " ) for the English language, because it only has singular, and plural.
Some languages in formaer Yoguslavia have dual in addition, so their array
would be  ( 0: " x != 1 " , 1: " x != 2 "), and the logic of English 1st, 2nd,
3rd, 4th, ... 11th, ... 21st, ... would be represented by ( 0: " ( 1 == ( x mod
10 ) ) && ( 11 != ( x mod 100 ) ) , 1: " ( 2 == ( x mod 10 ) ) && ( 12 != ( x
mod 100 ) ) ,  2: " ( 3 == ( x mod 10 ) ) && ( 13 != ( x mod 100 ) ) )
Implemeters of GRAMMAR can likely pretty easily provide lists of expressions in
both php and JS notation (even as messages in the MediaWiki name space) - all
the rest would be standard.


Coming back to GENDER above, and GRAMMAR, too, this split of 1.get index,
2.lookup result
would lessen the work to be done for those, since step 2. (lookup result) would
be identical
for each of them, streamlining the code for both the php and JS
implementations.
As Roan stes, this would be easily reusable in the future, should we require
more variablility.


-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

Reply via email to