https://bugzilla.wikimedia.org/show_bug.cgi?id=29005
Santhosh Thottingal <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |INVALID --- Comment #14 from Santhosh Thottingal <[email protected]> 2011-05-26 07:57:04 UTC --- (In reply to comment #11) > >Many people prefer to read the language in a particular way > > Please please please no one make that into a preference. We're talking about > unicode code points, not background colours. > > The two ways of encoding the character *should* be identical to the user, they > aren't - mostly due to crappy software support, but they should be [in the > ideal world, well in the ideal world there wouldn't be two ways to encode a > single character...]. In ideal world, we expect that. But in real world, dual encoding is there, at least for Malayalam. To make things simple: A letter L is written in L1 way. And in 2009, Unicode said it can be written in L2 way too. And asked applications to support both. Obviously many applications failed to do this. Unicode did not define that L1 and L2 are equal. So big issues with search, sort.. what not?. ml wikipedia decided to keep the data in L2 using a force conversion. Many websites decide to stick with L1 for stability, backward compatibility issues until there is a Unicode definition stating L1 == L2. because that is the minimum version they(not limited to websites, os and applications too)can support. At the same time L1 is well supported in majority of applications(Google chrome used to support it , from chrome 6.0 to chrome L1 it was broken, now fixed). There are fonts which does not show same glyph for L1 and L2 because the typographers care about the language and aware of dual encoding issues. So to make everybody happy, just for these extreme cases, I added a feature to do L2->L1 conversion. So that users can view/use L1 which is working in the systems for many years. It is not meant for all languages or for all fonts. And it is a configuration entry. L1 vs L2 is very controversial issue. And it becomes more complex when I say that there are more than one L with this issue. > *Per comment 1, I'm also unclear how this could break interlinking, since > they're all normalized to one form on the mediawiki side (While I guess it > could if the content language is not ml, since we only do the normalization > for > ml, but that seems like an edge case) You are correct. It does not break any interlinking. Since there is no reproducible case how this option breaks anything, I explained my best why it was added, shall we close it? Finding out broken versions of the browser(In our case chrome 6 to 11) and changing extension behavior based on that...Should we really need to do that? Considering Chrome does not support webfonts(complex script webfonts. Malayalam is an example) at all till Chrome 11, it seems unnecessary. Let us just declare that "Chrome was broken, and was not supporting Malayalam rendering or Malayalam webfonts till version 12". I hope that helps. Proof is bug 45840 and 78155 of chrome. -- 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 [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
