Hello,
I'm testing etoys-dev-4.0, with etoysV4.sources and a new VM linux version, If I set the pangoRenderer Preference to Off and I change the language (french, german...)... no problem, but if I want spanish (like my machine) automatically pangoRenderer put On. In this situation, even if I set again pangoRenderer Preference to Off when I save the image automatically pangoRenderer put On again. I do not know reallly if this process is "for my machine only"
regards
Hi, Antonio,
I'm testing etoys-dev-4.0, with etoysV4.sources and a new VM linux version, If I set the pangoRenderer Preference to Off and I change the language (french, german...)... no problem, but if I want spanish (like my machine) automatically pangoRenderer put On. In this situation, even if I set again pangoRenderer Preference to Off when I save the image automatically pangoRenderer put On again. I do not know reallly if this process is "for my machine only"
I tried to reproduce it, but not successfully. One thing that might affect is that you actually have a different etoys.mo file for Spanish, and your etoys-dev-4.0 finds it? The system trys to decide whether it should turn it on or not by looking at some phrases and specs in the .mo file.
-- Yoshiki
On Sat, Oct 18, 2008 at 6:10 AM, Yoshiki Ohshima yoshiki@vpri.org wrote:
Hi, Antonio,
I'm testing etoys-dev-4.0, with etoysV4.sources and a new VM linux version, If I set the pangoRenderer Preference to Off and I change the language (french, german...)... no problem, but if I want spanish (like my machine) automatically pangoRenderer put On. In this situation, even if I set again pangoRenderer Preference to Off when I save the image automatically pangoRenderer put On again. I do not know reallly if this process is "for my machine only"
I tried to reproduce it, but not successfully. One thing that might affect is that you actually have a different etoys.mo file for Spanish, and your etoys-dev-4.0 finds it? The system trys to decide whether it should turn it on or not by looking at some phrases and specs in the .mo file.
Antonio, Here is the section in PO/POT that Yoshiki mentioned: (excerpt from the version on Pootle) -----(from here) #: Language name as you'd like it to appear in the Languages menu msgid "Language-Name" msgstr "Nombre-Lenguaje"
#: Scale to apply to font size (2 for twice as large) msgid "Font-Scale" msgstr ""
#: Directionality of language msgid "Language-Direction" msgstr "Dirección-Lenguaje"
#: Use this if you do not want any of the text to be bolded, for legibility msgid "Suppress-Bold" msgstr ""
#: Font to use on a Windows system msgid "Win-Font" msgstr ""
#: Font to use on a Mac system msgid "Mac-Font" msgstr ""
#: Font to use on a Linux system msgid "Linux-Font" msgstr "" -----(excerpt to here)
These are not translation data but special configuration. see http://lists.laptop.org/pipermail/etoys/2008-August/002570.html and http://lists.laptop.org/pipermail/etoys/2008-September/002586.html. detail was explained there.
In short, your version (you sent me) needs fix :-) The version on Pootle also needs fix for "Language-Name" and "Language-Direction".
/Korakurider
-- Yoshiki _______________________________________________ Etoys mailing list Etoys@lists.laptop.org http://lists.laptop.org/listinfo/etoys
On Saturday 18 Oct 2008 2:40:01 am Yoshiki Ohshima wrote:
I tried to reproduce it, but not successfully. One thing that might affect is that you actually have a different etoys.mo file for Spanish, and your etoys-dev-4.0 finds it? The system trys to decide whether it should turn it on or not by looking at some phrases and specs in the .mo file
What was the rationale behind such a logic?
Locale is a poor determinant of rendering method. I would expect the method to be text style tag rather than spread all over the place like this. The current approach seems to add complexity to an already complex issue of multilingual text.
Did I miss something? .. Subbu
At Sat, 18 Oct 2008 11:30:38 +0530, K. K. Subramaniam wrote:
On Saturday 18 Oct 2008 2:40:01 am Yoshiki Ohshima wrote:
I tried to reproduce it, but not successfully. One thing that might affect is that you actually have a different etoys.mo file for Spanish, and your etoys-dev-4.0 finds it? The system trys to decide whether it should turn it on or not by looking at some phrases and specs in the .mo file
What was the rationale behind such a logic?
Locale is a poor determinant of rendering method. I would expect the method to be text style tag rather than spread all over the place like this. The current approach seems to add complexity to an already complex issue of multilingual text.
What is text style tag? and what do you mean by spread all over the place?
There are a few special "phrases" in the translation file that effectively specify the pango flag. The translators can specify the appropriate value so it can be set without the developers effort.
Did I miss something? .. Subbu
But, at the same time, the current implementation was done too quickly for the 8.2 release, and not great. We should surely fix it.
-- Yoshiki
On Fri, 17 Oct 2008, Yoshiki Ohshima wrote:
At Sat, 18 Oct 2008 11:30:38 +0530, K. K. Subramaniam wrote:
On Saturday 18 Oct 2008 2:40:01 am Yoshiki Ohshima wrote:
I tried to reproduce it, but not successfully. One thing that might affect is that you actually have a different etoys.mo file for Spanish, and your etoys-dev-4.0 finds it? The system trys to decide whether it should turn it on or not by looking at some phrases and specs in the .mo file
What was the rationale behind such a logic?
Locale is a poor determinant of rendering method. I would expect the method to be text style tag rather than spread all over the place like this. The current approach seems to add complexity to an already complex issue of multilingual text.
What is text style tag? and what do you mean by spread all over the place?
There are a few special "phrases" in the translation file that effectively specify the pango flag. The translators can specify the appropriate value so it can be set without the developers effort.
Did I miss something? .. Subbu
But, at the same time, the current implementation was done too quickly for the 8.2 release, and not great. We should surely fix it.
-- Yoshiki
Obviously there are several languages where these "phrases" are translated the wrong way, i.e. literally instead of what they're meant for - despite of the comments in the translation files.
Being a translator (language-admin for German) myself, I think, etoys.mo is the wrong place for the following strings:
(excerpt from the version on Pootle) -----(from here) #: Scale to apply to font size (2 for twice as large) msgid "Font-Scale" msgstr ""
#: Use this if you do not want any of the text to be bolded, for legibility msgid "Suppress-Bold" msgstr ""
#: Font to use on a Windows system msgid "Win-Font" msgstr ""
#: Font to use on a Mac system msgid "Mac-Font" msgstr ""
#: Font to use on a Linux system msgid "Linux-Font" msgstr "" -----(excerpt to here)
Not being a developer, I have no idea which values to put in there. Maybe "Win-Font", "Mac-Font" and "Linux-Font" are reasonable for languages needing special glyphs (I just don't know that, whence I left them empty), but "Font-Scale" and "Suppress-Bold" should rather be user-preferences than something translators have to decide about, I'd say.
Markus ----------------------------------------------- Markus Schlager m.slg@gmx.de
On Saturday 18 Oct 2008 11:51:35 am Yoshiki Ohshima wrote:
Locale is a poor determinant of rendering method. I would expect the method to be text style tag rather than spread all over the place like this. The current approach seems to add complexity to an already complex issue of multilingual text.
What is text style tag?
I meant an attribute associated with a piece of text (e.g. strong, emphasis, language, script, glyph variant) rather than the global environment. Notice how Project>>displayProgressWithJump has to turn usePango to false to display jumping guy.
and what do you mean by spread all over the place?
I meant the low-level rendering mechanism has leaked into higher level methods. Pango is just one of the many rendering methods in Linux and needs to be encapsulated within a rendering facade. The global usePango check is called from methods in LanguageEnvironment, Locale. If methods like StringMorph>>measureContents has to compute width by checking for every possible rendering method, then the complexity will soon get out of hand.
Did I miss something? .. Subbu
But, at the same time, the current implementation was done too quickly for the 8.2 release, and not great. We should surely fix it.
I understand the pressures and the issue gets quite complicated once you move beyond Latin-1 text. My concern was about lack of encapsulation and the proliferation of usePango and checks. Given XO's global deployment scenario, the code should be ready to take on different renderers. Can't we build upon TeX's approach of separating laying out text and rendering glyphs?
Subbu
Hi, Markus,
Obviously there are several languages where these "phrases" are translated the wrong way, i.e. literally instead of what they're meant for - despite of the comments in the translation files.
Yes.
Being a translator (language-admin for German) myself, I think, etoys.mo is the wrong place for the following strings:
Not being a developer, I have no idea which values to put in there. Maybe "Win-Font", "Mac-Font" and "Linux-Font" are reasonable for languages needing special glyphs (I just don't know that, whence I left them empty), but "Font-Scale" and "Suppress-Bold" should rather be user-preferences than something translators have to decide about, I'd say.
The set was brought from Scratch, but does not map well with the current Etoys features. The idea even was that Scratch had larger number of languages supported so the data should have been easily migrated from Scratch... But it was not the case for various reasons.
-- Yoshiki
At Mon, 20 Oct 2008 07:03:57 +0530, K. K. Subramaniam wrote:
On Saturday 18 Oct 2008 11:51:35 am Yoshiki Ohshima wrote:
Locale is a poor determinant of rendering method. I would expect the method to be text style tag rather than spread all over the place like this. The current approach seems to add complexity to an already complex issue of multilingual text.
What is text style tag?
I meant an attribute associated with a piece of text (e.g. strong, emphasis, language, script, glyph variant) rather than the global environment. Notice how Project>>displayProgressWithJump has to turn usePango to false to display jumping guy.
Well, yeah they do have the flag. But there should be a way to switch them globally.
and what do you mean by spread all over the place?
I meant the low-level rendering mechanism has leaked into higher level methods. Pango is just one of the many rendering methods in Linux and needs to be encapsulated within a rendering facade. The global usePango check is called from methods in LanguageEnvironment, Locale. If methods like StringMorph>>measureContents has to compute width by checking for every possible rendering method, then the complexity will soon get out of hand.
That is a valid concern. A library/platform neutral interface to these renderer would be a good idea.
But, at the same time, the current implementation was done too quickly for the 8.2 release, and not great. We should surely fix it.
I understand the pressures and the issue gets quite complicated once you move beyond Latin-1 text. My concern was about lack of encapsulation and the proliferation of usePango and checks. Given XO's global deployment scenario, the code should be ready to take on different renderers.
Yes.
Can't we build upon TeX's approach of separating laying out text and rendering glyphs?
That is yet another part of the topic, but it would be good.
-- Yoshiki
etoys-dev@lists.squeakfoundation.org
-
antonio -
K. K. Subramaniam -
Korakurider -
Markus Schlager -
Yoshiki Ohshima