On Tue, Aug 31, 2010 at 09:29, Richard Fairhurst <richard(a)systemed.net> wrote:
> Ævar Arnfjörð Bjarmason wrote:
>>
>> On Sun, Aug 29, 2010 at 16:54, Nop<ekkehart(a)gmx.de> wrote:
>>>
>>> And on a more general note: Is there a concept for the
>>> internationalization
>>> of P2?
>>
>> It could use the system that Potlatch v1 does. It's relatively easy to
>> add support for that.
>
> P2 is a slightly different kettle of fish because Flex is involved. You
> can't just pull stuff in at runtime (as P1 does) without making the .mxml
> files unspeakably horrible.
Yeah, I haven't looked at how to do it in PL2...
> This is the best alternative I've found:
> http://www.gridlinked.info/amazing-i18n-solutions-for-flex-3-4/
> which I guess could be wired up to translatewiki somehow.
..but whatever it ends up using should be easy to hook into
Translatewiki. It's just a matter of the messages being available
somewhere for Translatewiki to pull them from, and for it to update it
and submit them back to PL2.
> (From my point of view, the one thing I'd like to improve over P1's
> internationalisation is that the English messages should be in the source,
> not in en.yml. It makes the UI much more readable and maintainable.)
Yeah, we discussed this on IRC a while back. You'd like something more
gettext-like, while Translatewiki is more geared around the "abstract
key => translation" model.
But it can do gettext-like too, it does this for Status.Net
already. It just does so by deriving a key from the raw message
itself.
This means though that when you change the original message you won't
get the old message for context in the history, and translators will
see it as a brand new message instead of seeing a diff between the old
and new.
This is partly just due to lack of support in Translatewiki, but it's
also somewhat inherent in the gettext model. GNU gettext sometimes
fails to mark messages as fuzzy on upgrades and thinks they're brand
new messages if you move the source around a bit.
So while it might be a bit easier for English speaking developers to
read gettext-y source it's also useful to keep in mind the extra work
that may be created for translators.
And much of the issue for developers can be easily mitigated by
choosing more understandable keys in the first place, something that
Potlatch 1 *didn't* do, mostly because the YAML has was a flat
namespace and I had to work with existing code, so they weren't very
internally consistent. The Rails Port is a lot better in this regard.
Anyway, whatever PL2 ends up going for I'd be happy to help with it.
I've been trying to figure out if it's possible to slightly change how
message strings are processed, for the particular case of sending them
to a Javascript-heavy application.
The WMF has been working on a lot of interface improvements, and these
things necessarily lean heavily on Javascript.
There are many cases where we want to do some late message parsing on
the client, like
'[$1 Click here to advance to the next item]'
'You have uploaded $1 {{PLURAL:$1|file|files}}'
However there is a lot of other kinds of parsing that could and should
be done on the server, like
'From {{SITENAME}}'
'[[Special:SpecialPages|{{int:specialpages}}]]'
So we have two options, as far as I can tell:
OPTION 1:
Include a wikitext parser in Javascript, that also knows how to fetch
int:strings and other such values when it needs them. This is
undesirable for obvious reasons.
Michael Dale actually did a lot of this already for his JS2 project, and
his solution works. But I'm taking another look at the problem.
OPTION 2:
Figure out some way to alter parsing on the server for Javascript
messages, such that things like {{SITENAME}} are parsed, but {{PLURAL}}
isn't (or, the parse results emits an identical {{PLURAL}} template call).
Then a much simpler parser -- probably based on regular expressions --
can be deployed to the client.
Roan Kattouw and Trevor Parscal are working on a new Resource Loader
that may be able to do some of the above. Also, Niklaus Laxstrom is
working on a new Message class that looks like it will be far more
amenable to this sort of thing.
In the meantime...
I've been messing around with the current system, and it seems that
there isn't any good way to do this that doesn't involve evil dabbling
with global parser hooks. I tried creating a special Language-like
object that I could pass into message parsing, which essentially wrapped
all calls to another Language object except for convertPlural and mCode.
But it seems that this won't work either since so many of the
ParserOptions are retrieved from global settings in strange ways.
Any thoughts?
--
Neil Kandalgaonkar <neilk(a)wikimedia.org>
On 8/11/10 12:40 AM, Roan Kattouw wrote:
> 2010/8/11 Neil Kandalgaonkar<neilk(a)wikimedia.org>:
>> OPTION 2:
>>
>> Figure out some way to alter parsing on the server for Javascript messages,
>> such that things like {{SITENAME}} are parsed, but {{PLURAL}} isn't (or, the
>> parse results emits an identical {{PLURAL}} template call).
>>
> What I think would be the easiest solution is to simply /mark/
> messages as needing server-side parsing. If such a flag is set, we'd
> run the message through parsemag (or maybe even parse, in some cases)
> before sending them to the client; if not, we'd send it to the client
> verbatim and the client-side parser (with its very limited wikitext
> support) would handle it.
>
> Roan Kattouw (Catrope)
Just wanted to add some clarity.
The point here is not that detecting which messages need to be parsed
fully or partially is hard, it's that extending the parser to render
{{PLURAL}} and {{GENDER}} differently has been proving to be
problematic. The concept is, some processing could be differed to the
client, such as which plural or gender case to use, in which case we
would want to process the entire message, except {{PLURAL}} and {{GENDER}}.
Marking messages as "render me on the server" or "render me on the
client" doesn't solve the problem - we want to process many messages on
both, such as "{{int:something}} tests {{PLURAL:$1|this thing|these $1
things}}", which would be transformed to "Something tests
{{PLURAL:$1|this|these $1 things}}", so the client can finish processing
it without having to do an API call back to the server to get the value
of {{int:something}}.
- Trevor
Hey Praveen,
This mailing list is more for the translation of Wikimedia
Foundation-related things, like WikimediaFoundation.org, the board
elections, fundraising stuff, and other things like that.
MediaWiki-related translation questions should be asked on
translatewiki itself[1]. (There is a mediawiki-i18n mailing list[2]
too, but it's not really used.)
Sorry for the confusion!
Casey
[1]http://translatewiki.net/wiki/Support
[2]https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n
On Tue, Aug 10, 2010 at 2:03 PM, praveenp <me.praveen(a)gmail.com> wrote:
> Hi,
> I think it is better to show brackets or any other symbols on message itself. Many language has a different sentence structure, so, automatically inserted (read as in English way) symbols cannot merge, with localized message. It is highly stressful to manage them with sentence (or part of sentence) structure. I afraid in this message http://translatewiki.net/wiki/MediaWiki:Watchlistfor2 it is almost impossible in Malayalam, so I am trapezing on words. If this is the case for Malayalam I am sure that all Indic languages are facing same problem, and probably many other languages.
>
> Praveen
>
>
>
> _______________________________________________
> Translators-l mailing list
> Translators-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/translators-l
>
--
Casey Brown
Cbrown1023