Last modified: 2013-10-18 15:49:20 UTC
Let's start 2013 with a fun bug. It would be very useful when working on the skins or other bits of the interface. Currently, to test variants handling, you have to switch the entire wiki to a language that uses variant conversion, and unfortunately it seems like all of them use non-Latin alphabets, which makes working with them considerably harder if know them than if they were in a latin script at least. With this, you would just set $wgUsePigLatinVariant (or something similar) to true and be able to test. Of course we could use piratey or lolcat language instead of pig latin, but it seems the nicest to me (and easier to implement).
Please don't mark bugs as resolved (particularly resolved/wontfix) without a comment. Re-opening for now.
If we want to explore this option, I would recommend to take a look to two small applications: Jive and valspeak, as there are very easy to implement. I have to note these applications could be in violation with modern expectation of decency and politeness. For example, the jive application [1] is built with the following code: #include <stdio.h> char *yylex(); int main() { char *line; while(line = yylex()){ printf("%s", line); } return 0; } And this lex list: http://stuff.mit.edu/afs/sipb/user/rfrench/src/jive/jive.l The valspeak lex list: https://groups.google.com/group/net.sources/msg/be14e2cfcdf7eb06?dmode=source [1] https://groups.google.com/group/net.sources/tree/browse_frm/month/1986-10/e5cbd0d14f430065?rnum=81&_done=/group/net.sources/browse_frm/month/1986-10?&pli=1 Strangely, the jive application reaches FreeBSD port, but not the valspeak.
(In reply to comment #1) > Please don't mark bugs as resolved (particularly resolved/wontfix) without a > comment. Comment: looks like what you want is rather bug 38486.
(In reply to comment #3) > Comment: looks like what you want is rather bug 38486. While slightly similar, this doesn't seem like the same thing to me (although solutions to one of them could solve the other as well, in some cases). This bug is from the perspective of a skin developer, that one is from an extension developer. I went through some pain to implement interface for variants in CologneBlue when I was rewirting it, and I've been sitting on this idea since. Well, I'm not sure. I think we should just try implementing something ;) (I could work on this pig Latin variant if there was a reasonable chance of it getting merged). [Reopening for now; maybe it's a dupe, but certainly not a wontfix, is it?]
The language converter works on chars or substrings instead of (space-delimited) words, so I don't think it's easy to adapt a word-based conversion here (correct me if I'm wrong). Since this is not a serious variant development, maybe we can choose l33t or something similar instead?
Hey, just a converter between UPPERCASE and lowercase is enough.
See also bug 26121 comment 12.
Btw, In my experiance serbian is best for testing things when your eyes are used to a latin script
The converter works abstractly on text not individual characters. So I'd think it should be completely fine to do word based conversions. Heck, I'm already doing word based conversions. I hacked the variant system with a custom language to make it so that character names in a certain animanga wiki can vary by what version of the series you've been accustomed to (The original romaji, manga translation, subtitled translations, dub translations, and translations of alternate dubs can have different translations for the same character). Though a recent upgrade may have broke some of the code I used to hackily load the language variants in to mw in the first place. Note that we have another bug contemplating the idea of implementing US, Canada, UK, etc... English as variants.
(In reply to comment #9) > The converter works abstractly on text not individual characters. So I'd > think > it should be completely fine to do word based conversions. > > Heck, I'm already doing word based conversions. I hacked the variant system > with a custom language to make it so that character names in a certain > animanga > wiki can vary by what version of the series you've been accustomed to (The > original romaji, manga translation, subtitled translations, dub translations, > and translations of alternate dubs can have different translations for the > same > character). Though a recent upgrade may have broke some of the code I used to > hackily load the language variants in to mw in the first place. > > Note that we have another bug contemplating the idea of implementing US, > Canada, UK, etc... English as variants. Yeah you have to override LanguageConverter::translate() then, and can't make use of the default conversion table holder (ReplacementArray).
Change 72053 had a related patch set uploaded by Liangent: (bug 43547) New language variant en-x-piglatin DO NOT MERGE https://gerrit.wikimedia.org/r/72053
(In reply to comment #9) > .. > Note that we have another bug contemplating the idea of implementing US, > Canada, UK, etc... English as variants. bug 31015? It would be useful to start that set of variants, with just the basic transforms; the implementation of a viable set of conversions could then develop over time.
