Hi,
Should the system scripts, messages and the likewise composed wordings (e.g. removeAllFromPatchDisplayList, getTextColor, makeNewDrawingIn, mouseMove etc) — be literally translated? Suggestions welcomed.
— paulo
On Oct 7, 2007, at 20:45 , Paulo Drummond wrote:
Hi,
Should the system scripts, messages and the likewise composed wordings (e.g. removeAllFromPatchDisplayList, getTextColor, makeNewDrawingIn, mouseMove etc) — be literally translated? Suggestions welcomed.
IMHO, they should not have those camelCase names in the first place ... this is even wrong for English.
I think for now they should be translated to regular phrases with spaces. Or is there any good reason for those strange spellings? Not sure when we will get around to fixing them ...
- Bert -
Thanks, Bert.
Correct me if I'm wrong, but if they were created with a special meaning they should remain as a single word. And this cohesiveness may explain the camelCasing. On the other hand, as they are not used (or purposely not shown) on the XO Etoys interface, so I don't see why they should be translated at all.
On Oct 7, 2007, at 4:27 PM, Bert Freudenberg wrote:
On Oct 7, 2007, at 20:45 , Paulo Drummond wrote:
Hi,
Should the system scripts, messages and the likewise composed wordings (e.g. removeAllFromPatchDisplayList, getTextColor, makeNewDrawingIn, mouseMove etc) — be literally translated? Suggestions welcomed.
IMHO, they should not have those camelCase names in the first place ... this is even wrong for English.
I think for now they should be translated to regular phrases with spaces. Or is there any good reason for those strange spellings? Not sure when we will get around to fixing them ...
- Bert -
Well, you are only partly wrong. Some of these are visible in the interface, like removeAllFromPatchDisplayList appears in the viewer of a Kedama world.
That getTextColor shows seems to be a bug. It is not actually used directly, but appears as the "color" property in a viewer on a Text.
makeNewDrawingIn is used in a ReferenceMorph.
Not sure where mouseMove is used, that may or may not be a bug.
And they still should be translated - even if they are purposely not shown, kids can unlock them. Etoys is an environment that goes beyond the tile scripting you see by default.
- Bert -
On Oct 7, 2007, at 21:55 , Paulo Drummond wrote:
Thanks, Bert.
Correct me if I'm wrong, but if they were created with a special meaning they should remain as a single word. And this cohesiveness may explain the camelCasing. On the other hand, as they are not used (or purposely not shown) on the XO Etoys interface, so I don't see why they should be translated at all.
On Oct 7, 2007, at 4:27 PM, Bert Freudenberg wrote:
On Oct 7, 2007, at 20:45 , Paulo Drummond wrote:
Hi,
Should the system scripts, messages and the likewise composed wordings (e.g. removeAllFromPatchDisplayList, getTextColor, makeNewDrawingIn, mouseMove etc) — be literally translated? Suggestions welcomed.
IMHO, they should not have those camelCase names in the first place ... this is even wrong for English.
I think for now they should be translated to regular phrases with spaces. Or is there any good reason for those strange spellings? Not sure when we will get around to fixing them ...
- Bert -
Ok. And I know about the openness idea of OLPC, XO (Etoys incuded). Then, my question changes to: is it safe (systemwise) translating ALL these composed things into separate words?
— paulo
On Oct 7, 2007, at 5:39 PM, Bert Freudenberg wrote:
Well, you are only partly wrong. Some of these are visible in the interface, like removeAllFromPatchDisplayList appears in the viewer of a Kedama world.
That getTextColor shows seems to be a bug. It is not actually used directly, but appears as the "color" property in a viewer on a Text.
makeNewDrawingIn is used in a ReferenceMorph.
Not sure where mouseMove is used, that may or may not be a bug.
And they still should be translated - even if they are purposely not shown, kids can unlock them. Etoys is an environment that goes beyond the tile scripting you see by default.
- Bert -
On Oct 7, 2007, at 21:55 , Paulo Drummond wrote:
Thanks, Bert.
Correct me if I'm wrong, but if they were created with a special meaning they should remain as a single word. And this cohesiveness may explain the camelCasing. On the other hand, as they are not used (or purposely not shown) on the XO Etoys interface, so I don't see why they should be translated at all.
On Oct 7, 2007, at 4:27 PM, Bert Freudenberg wrote:
On Oct 7, 2007, at 20:45 , Paulo Drummond wrote:
Hi,
Should the system scripts, messages and the likewise composed wordings (e.g. removeAllFromPatchDisplayList, getTextColor, makeNewDrawingIn, mouseMove etc) — be literally translated? Suggestions welcomed.
IMHO, they should not have those camelCase names in the first place ... this is even wrong for English.
I think for now they should be translated to regular phrases with spaces. Or is there any good reason for those strange spellings? Not sure when we will get around to fixing them ...
- Bert -
Yes, it is safe (if not, it should be considered as a bug). Although I hate that there are such camel case msgids. I assume those are just for historical reason.
- Takashi
Paulo Drummond wrote:
Ok. And I know about the openness idea of OLPC, XO (Etoys incuded). Then, my question changes to: is it safe (systemwise) translating ALL these composed things into separate words?
— paulo
On Oct 7, 2007, at 5:39 PM, Bert Freudenberg wrote:
Well, you are only partly wrong. Some of these are visible in the interface, like removeAllFromPatchDisplayList appears in the viewer of a Kedama world.
That getTextColor shows seems to be a bug. It is not actually used directly, but appears as the "color" property in a viewer on a Text.
makeNewDrawingIn is used in a ReferenceMorph.
Not sure where mouseMove is used, that may or may not be a bug.
And they still should be translated - even if they are purposely not shown, kids can unlock them. Etoys is an environment that goes beyond the tile scripting you see by default.
- Bert -
On Oct 7, 2007, at 21:55 , Paulo Drummond wrote:
Thanks, Bert.
Correct me if I'm wrong, but if they were created with a special meaning they should remain as a single word. And this cohesiveness may explain the camelCasing. On the other hand, as they are not used (or purposely not shown) on the XO Etoys interface, so I don't see why they should be translated at all.
On Oct 7, 2007, at 4:27 PM, Bert Freudenberg wrote:
On Oct 7, 2007, at 20:45 , Paulo Drummond wrote:
Hi,
Should the system scripts, messages and the likewise composed wordings (e.g. removeAllFromPatchDisplayList, getTextColor, makeNewDrawingIn, mouseMove etc) — be literally translated? Suggestions welcomed.
IMHO, they should not have those camelCase names in the first place ... this is even wrong for English.
I think for now they should be translated to regular phrases with spaces. Or is there any good reason for those strange spellings? Not sure when we will get around to fixing them ...
Thanks, Takashi! I can say there won't be humps in my translations ;-)
— paulo
On Oct 8, 2007, at 1:32 AM, Takashi Yamamiya wrote:
Yes, it is safe (if not, it should be considered as a bug). Although I hate that there are such camel case msgids. I assume those are just for historical reason.
- Takashi
Paulo Drummond wrote:
Ok. And I know about the openness idea of OLPC, XO (Etoys incuded). Then, my question changes to: is it safe (systemwise) translating ALL these composed things into separate words? — paulo On Oct 7, 2007, at 5:39 PM, Bert Freudenberg wrote:
Well, you are only partly wrong. Some of these are visible in the interface, like removeAllFromPatchDisplayList appears in the viewer of a Kedama world.
That getTextColor shows seems to be a bug. It is not actually used directly, but appears as the "color" property in a viewer on a Text.
makeNewDrawingIn is used in a ReferenceMorph.
Not sure where mouseMove is used, that may or may not be a bug.
And they still should be translated - even if they are purposely not shown, kids can unlock them. Etoys is an environment that goes beyond the tile scripting you see by default.
- Bert -
On Oct 7, 2007, at 21:55 , Paulo Drummond wrote:
Thanks, Bert.
Correct me if I'm wrong, but if they were created with a special meaning they should remain as a single word. And this cohesiveness may explain the camelCasing. On the other hand, as they are not used (or purposely not shown) on the XO Etoys interface, so I don't see why they should be translated at all.
On Oct 7, 2007, at 4:27 PM, Bert Freudenberg wrote:
On Oct 7, 2007, at 20:45 , Paulo Drummond wrote:
Hi,
Should the system scripts, messages and the likewise composed wordings (e.g. removeAllFromPatchDisplayList, getTextColor, makeNewDrawingIn, mouseMove etc) — be literally translated? Suggestions welcomed.
IMHO, they should not have those camelCase names in the first place ... this is even wrong for English.
I think for now they should be translated to regular phrases with spaces. Or is there any good reason for those strange spellings? Not sure when we will get around to fixing them ...
On Oct 8, 2007, at 6:32 , Takashi Yamamiya wrote:
Yes, it is safe (if not, it should be considered as a bug). Although I hate that there are such camel case msgids. I assume those are just for historical reason.
There is a method that changes the internal name (such as "forward:") into the user-visible name ("forward by"). However, it is only made of a long list of names where the user-visible names actually differ. It did not translate camel case into space-separated words.
I just published an update to solve this - the viewer should now only ever show phrases with words separated by spaces. I also patched the gettext exporter so the generated pot file should be fine. It also migrates translations from the old camelCase format - if "my example" has no existing translation, but "myExample" does, it uses that one.
I did *not* modify the cached translations, and neither the lookup, but it appears to work so far.
Also, we have a few more places with camelCase, like the events in scriptors. Not sure if they are as easy to change.
- Bert -
etoys-dev@lists.squeakfoundation.org