When in
etoys-dev.image
I can open a halo on an EllipseMorph, click on the debug icon and then select "save morph in file." That puts a file, for example, grey.morph, assuming that's the name I gave to the morph, in my Squeak directory. The FillInTheBlank morph that assists with the naming process automatically appends ".morph" to the name I select, in this case "grey."
If I open a HolderMorph and put a few EllipseMorphs into it and if I open a halo on the HolderMorph and then try to save it in the same way, the dialogue box gives me the option to save the holder as a .project file.
When I try to bring that back into Squeak, it comes in as a something or other that takes over the World and can't be worked with in any way that I can determine.
So, my question is what's the best way to export a Holder with whatever objects it contains. The context is a student in my class has a holder with 57 or so sketches and we'd like to move it (the holder with the sketches) from from one image to another.
Thanks in advance,
Mark
On 09.04.2008, at 10:33, polishookm wrote:
When in
etoys-dev.image
I can open a halo on an EllipseMorph, click on the debug icon and then select "save morph in file." That puts a file, for example, grey.morph, assuming that's the name I gave to the morph, in my Squeak directory. The FillInTheBlank morph that assists with the naming process automatically appends ".morph" to the name I select, in this case "grey."
If I open a HolderMorph and put a few EllipseMorphs into it and if I open a halo on the HolderMorph and then try to save it in the same way, the dialogue box gives me the option to save the holder as a .project file.
When I try to bring that back into Squeak, it comes in as a something or other that takes over the World and can't be worked with in any way that I can determine.
So, my question is what's the best way to export a Holder with whatever objects it contains. The context is a student in my class has a holder with 57 or so sketches and we'd like to move it (the holder with the sketches) from from one image to another.
Do as you did, and simply rename the file to "xyz.morph".
Maybe that option could be made more obvious...
- Bert -
Thanks Bert, That worked perfectly with a small demonstration example. If it doesn't work for my student with 57 or so objects in a holder, I'll report back.
Yes, I agree with you - if the process could be more obvious, that would be helpful :)
.... (But I appreciate your quick reply ... thanks again! )
Bert Freudenberg wrote:
On 09.04.2008, at 10:33, polishookm wrote:
When in
etoys-dev.image
I can open a halo on an EllipseMorph, click on the debug icon and then select "save morph in file." That puts a file, for example, grey.morph, assuming that's the name I gave to the morph, in my Squeak directory. The FillInTheBlank morph that assists with the naming process automatically appends ".morph" to the name I select, in this case "grey."
If I open a HolderMorph and put a few EllipseMorphs into it and if I open a halo on the HolderMorph and then try to save it in the same way, the dialogue box gives me the option to save the holder as a .project file.
When I try to bring that back into Squeak, it comes in as a something or other that takes over the World and can't be worked with in any way that I can determine.
So, my question is what's the best way to export a Holder with whatever objects it contains. The context is a student in my class has a holder with 57 or so sketches and we'd like to move it (the holder with the sketches) from from one image to another.
Do as you did, and simply rename the file to "xyz.morph".
Maybe that option could be made more obvious...
- Bert -
Etoys mailing list Etoys@lists.laptop.org http://lists.laptop.org/listinfo/etoys
I had same problem long time ago. It's tricky. Because a holder is just a morph, I think it is natural to remove this spacial case about PasteUpMorph and .project.
Cheers, - Takashi
polishookm wrote:
Thanks Bert, That worked perfectly with a small demonstration example. If it doesn't work for my student with 57 or so objects in a holder, I'll report back.
Yes, I agree with you - if the process could be more obvious, that would be helpful :)
.... (But I appreciate your quick reply ... thanks again! )
Bert Freudenberg wrote:
On 09.04.2008, at 10:33, polishookm wrote:
When in
etoys-dev.image
I can open a halo on an EllipseMorph, click on the debug icon and then select "save morph in file." That puts a file, for example, grey.morph, assuming that's the name I gave to the morph, in my Squeak directory. The FillInTheBlank morph that assists with the naming process automatically appends ".morph" to the name I select, in this case "grey."
If I open a HolderMorph and put a few EllipseMorphs into it and if I open a halo on the HolderMorph and then try to save it in the same way, the dialogue box gives me the option to save the holder as a .project file.
When I try to bring that back into Squeak, it comes in as a something or other that takes over the World and can't be worked with in any way that I can determine.
So, my question is what's the best way to export a Holder with whatever objects it contains. The context is a student in my class has a holder with 57 or so sketches and we'd like to move it (the holder with the sketches) from from one image to another.
Do as you did, and simply rename the file to "xyz.morph".
Maybe that option could be made more obvious...
You might add a feature request at
(Open a "new ticket" for the "etoys-activity" component)
- Bert -
On 09.04.2008, at 10:54, polishookm wrote:
Thanks Bert, That worked perfectly with a small demonstration example. If it doesn't work for my student with 57 or so objects in a holder, I'll report back.
Yes, I agree with you - if the process could be more obvious, that would be helpful :)
.... (But I appreciate your quick reply ... thanks again! )
Bert Freudenberg wrote:
On 09.04.2008, at 10:33, polishookm wrote:
When in
etoys-dev.image
I can open a halo on an EllipseMorph, click on the debug icon and then select "save morph in file." That puts a file, for example, grey.morph, assuming that's the name I gave to the morph, in my Squeak directory. The FillInTheBlank morph that assists with the naming process automatically appends ".morph" to the name I select, in this case "grey."
If I open a HolderMorph and put a few EllipseMorphs into it and if I open a halo on the HolderMorph and then try to save it in the same way, the dialogue box gives me the option to save the holder as a .project file.
When I try to bring that back into Squeak, it comes in as a something or other that takes over the World and can't be worked with in any way that I can determine.
So, my question is what's the best way to export a Holder with whatever objects it contains. The context is a student in my class has a holder with 57 or so sketches and we'd like to move it (the holder with the sketches) from from one image to another.
Do as you did, and simply rename the file to "xyz.morph".
Maybe that option could be made more obvious...
- Bert -
Etoys mailing list Etoys@lists.laptop.org http://lists.laptop.org/listinfo/etoys
I've added a ticket (#6868).
I guess one more step is to see if I can fix it it myself .... :)
Thanks -
Mark
Bert Freudenberg wrote:
You might add a feature request at
(Open a "new ticket" for the "etoys-activity" component)
- Bert -
On 09.04.2008, at 10:54, polishookm wrote:
Thanks Bert, That worked perfectly with a small demonstration example. If it doesn't work for my student with 57 or so objects in a holder, I'll report back.
Yes, I agree with you - if the process could be more obvious, that would be helpful :)
.... (But I appreciate your quick reply ... thanks again! )
Bert Freudenberg wrote:
On 09.04.2008, at 10:33, polishookm wrote:
When in
etoys-dev.image
I can open a halo on an EllipseMorph, click on the debug icon and then select "save morph in file." That puts a file, for example, grey.morph, assuming that's the name I gave to the morph, in my Squeak directory. The FillInTheBlank morph that assists with the naming process automatically appends ".morph" to the name I select, in this case "grey."
If I open a HolderMorph and put a few EllipseMorphs into it and if I open a halo on the HolderMorph and then try to save it in the same way, the dialogue box gives me the option to save the holder as a .project file.
When I try to bring that back into Squeak, it comes in as a something or other that takes over the World and can't be worked with in any way that I can determine.
So, my question is what's the best way to export a Holder with whatever objects it contains. The context is a student in my class has a holder with 57 or so sketches and we'd like to move it (the holder with the sketches) from from one image to another.
Do as you did, and simply rename the file to "xyz.morph".
Maybe that option could be made more obvious...
- Bert -
Etoys mailing list Etoys@lists.laptop.org http://lists.laptop.org/listinfo/etoys
Etoys mailing list Etoys@lists.laptop.org http://lists.laptop.org/listinfo/etoys
As best as I can tell, there's a saveOnFile implementation for PasteUpMorph and a saveOnFile implementation for Morph.
Is fixing the feature/bug in which a Holder because of "save morph in file" in the debug menu becomes holder.project (rather than holder.morph) as simple as editing references to .project in the 3 or so places it appears in PasteUpMorph >> saveOnFile .... so that .morph is used instead of .project?
As best as I can tell, PasteUpMorph >> saveOnFile knows how to recognize when a World is being saved (and thus needs to be a .pr file .... ?)
I'm sure this is all well known but it's definitely new for me ... :)
Thanks in advance ...
- Mark
polishookm wrote:
I've added a ticket (#6868).
I guess one more step is to see if I can fix it it myself .... :)
Thanks -
Mark
Bert Freudenberg wrote:
You might add a feature request at
(Open a "new ticket" for the "etoys-activity" component)
- Bert -
On 09.04.2008, at 10:54, polishookm wrote:
Thanks Bert, That worked perfectly with a small demonstration example. If it doesn't work for my student with 57 or so objects in a holder, I'll report back.
Yes, I agree with you - if the process could be more obvious, that would be helpful :)
.... (But I appreciate your quick reply ... thanks again! )
Bert Freudenberg wrote:
On 09.04.2008, at 10:33, polishookm wrote:
When in
etoys-dev.image
I can open a halo on an EllipseMorph, click on the debug icon and then select "save morph in file." That puts a file, for example, grey.morph, assuming that's the name I gave to the morph, in my Squeak directory. The FillInTheBlank morph that assists with the naming process automatically appends ".morph" to the name I select, in this case "grey."
If I open a HolderMorph and put a few EllipseMorphs into it and if I open a halo on the HolderMorph and then try to save it in the same way, the dialogue box gives me the option to save the holder as a .project file.
When I try to bring that back into Squeak, it comes in as a something or other that takes over the World and can't be worked with in any way that I can determine.
So, my question is what's the best way to export a Holder with whatever objects it contains. The context is a student in my class has a holder with 57 or so sketches and we'd like to move it (the holder with the sketches) from from one image to another.
Do as you did, and simply rename the file to "xyz.morph".
Maybe that option could be made more obvious...
- Bert -
Etoys mailing list Etoys@lists.laptop.org http://lists.laptop.org/listinfo/etoys
Etoys mailing list Etoys@lists.laptop.org http://lists.laptop.org/listinfo/etoys
Dear all,
The recent situation of etoy-translation is a little bit confusing for me. Is there a chance for some updates to the different images and on Pootle.
http://etoys.laptop.org/src/etoys-dev.zip http://etoys.laptop.org/src/etoys-image-and-pr.zip I downloaded and installed them and pulled all updates up to 1963
The recent images doesn't include the latest changes of translation strings in their pot/po-files (from Feb/Mar). It had to play around with the language-editor to get them somehow available. Is it possible for the developers to update the translations-strings in the images + pootle, in some kind of automatic procedure?
I can see only 6 different languages in the language selector in the nav-bar.
The etoys.image has a lang-directory, the etoys-dev.image has a po-directory. Any chance to unifiy them. The InternalLanguageEditor uses the po-directory for gettext export/import (both etoy+etoy-dev.image).
Any chance to include the latest translation-cs form ticket 6704 into the images and Pootle:-)
kind regards
Gerhard Steiner
Hi, Gerhard.
On 4/10/08, Gerhard Steiner gd.steiner@gmx.at wrote:
Dear all,
The recent situation of etoy-translation is a little bit confusing for me. Is there a chance for some updates to the different images and on Pootle.
http://etoys.laptop.org/src/etoys-dev.zip http://etoys.laptop.org/src/etoys-image-and-pr.zip I downloaded and installed them and pulled all updates up to 1963
The recent images doesn't include the latest changes of translation strings in their pot/po-files (from Feb/Mar). It had to play around with the language-editor to get them somehow available. Is it possible for the developers to update the translations-strings in the images + pootle, in some kind of automatic procedure? I can see only 6 different languages in the language selector in the nav-bar.
The downloadable files you mentioned are just result of the latest build and aren't package perfectly ready for use. Those don't contain compiled MOs, so basically you need to place MOs manually. Without MOs, Etoys work with in-image translations that we (developers) don't maintain anymore.
Do you have any reason that you don't want work with MOs external to image and you want to stick to in-image translations? I believe we don't want to (in usual situation). Here is why:
The Design of legacy-in-image translation dictionary is just one big original to translation mapping table and functionality is very limited. For example, with the legacy mechanism we can't implement context-aware translation you requested in the recent discussion. Other example is that add-on activity like DrGeoII can have its own translations (with TextDomain of gettext). But for in-image dictionary all translation including add-on ones needs to be unified.
The etoys.image has a lang-directory, the etoys-dev.image has a po-directory. Any chance to unifiy them.
We could have both directories in both archives :-)
The InternalLanguageEditor uses the po-directory for gettext export/import (both etoy+etoy-dev.image).
LanguageEditor still exist as-is for now, and you can import PO into in-image dictionary or export. But the limitation I explained above would affect you. If we introduce context or split big etoys.po into multiple pieces importing will not work.
Any chance to include the latest translation-cs form ticket 6704 into the images and Pootle:-)
This is different topic and still needs some work by developers...
kind regards
Gerhard Steiner
Etoys mailing list Etoys@lists.laptop.org http://lists.laptop.org/listinfo/etoys
On 10.04.2008, at 02:48, Korakurider wrote:
On 4/10/08, Gerhard Steiner gd.steiner@gmx.at wrote:
http://etoys.laptop.org/src/etoys-dev.zip http://etoys.laptop.org/src/etoys-image-and-pr.zip
Is it possible for the developers to update the translations- strings in the images + pootle, in some kind of automatic procedure?
It would be possible to
The downloadable files you mentioned are just result of thelatest build and aren't package perfectly ready for use. Those don't contain compiled MOs, so basically you need to place MOs manually.
Actually, the non-dev version should be ready for use. It has MOs.
The etoys.image has a lang-directory, the etoys-dev.image has a po-directory. Any chance to unifiy them.
We could have both directories in both archives :-)
Why? The one is the source, for developers, the other the compiled result, for users. Shipping POs to users doesn't make sense, and having POs in the dev zip would be redundant.
Any chance to include the latest translation-cs form ticket 6704 into the images and Pootle:-)
This is different topic and still needs some work by developers...
I wish there was a way to flag tickets that have a patch waiting for inclusion in the image ... It's too easy to forget about them. We should definitely push the changesets to the update stream (though I have not looked at them in detail, yet). And make a new release soonish.
- Bert -
(sent this before finishing) - Bert -
On 10.04.2008, at 06:28, Bert Freudenberg wrote:
On 10.04.2008, at 02:48, Korakurider wrote:
On 4/10/08, Gerhard Steiner gd.steiner@gmx.at wrote:
http://etoys.laptop.org/src/etoys-dev.zip http://etoys.laptop.org/src/etoys-image-and-pr.zip
Is it possible for the developers to update the translations- strings in the images + pootle, in some kind of automatic procedure?
It would be possible to
... automate this, but for various reasons it's a manual process. Some developer (usually Takashi) will move the files from where Pootle stored them into a release.
The downloadable files you mentioned are just result of the latest build and aren't package perfectly ready for use. Those don't contain compiled MOs, so basically you need to place MOs manually.
Actually, the non-dev version should be ready for use. It has MOs.
The etoys.image has a lang-directory, the etoys-dev.image has a po-directory. Any chance to unifiy them.
We could have both directories in both archives :-)
Why? The one is the source, for developers, the other the compiled result, for users. Shipping POs to users doesn't make sense, and having POs in the dev zip would be redundant.
Any chance to include the latest translation-cs form ticket 6704 into the images and Pootle:-)
This is different topic and still needs some work by developers...
I wish there was a way to flag tickets that have a patch waiting for inclusion in the image ... It's too easy to forget about them. We should definitely push the changesets to the update stream (though I have not looked at them in detail, yet). And make a new release soonish.
- Bert -
On 10.04.2008, at 06:28, Bert Freudenberg wrote:
On 10.04.2008, at 02:48, Korakurider wrote:
On 4/10/08, Gerhard Steiner gd.steiner@gmx.at wrote:
http://etoys.laptop.org/src/etoys-dev.zip http://etoys.laptop.org/src/etoys-image-and-pr.zip
Is it possible for the developers to update the translations- strings in the images + pootle, in some kind of automatic procedure?
It would be possible to
... automate this, but for various reasons it's a manual process. Some developer (usually Takashi) will move the files from where Pootle stored them into a release.
I've updated mo files in svn repository.
I was completely forgot the fact that we have two places for po, it's silly, sorry. Now I'm thinking to add commands into Makefile to automate this process, and finally remove all po files in svn except templates.
Cheers, - Takashi
On Fri, Apr 11, 2008 at 5:49 AM, Takashi Yamamiya tak@metatoys.org wrote:
I was completely forgot the fact that we have two places for po, it's silly, sorry. Now I'm thinking to add commands into Makefile to automate this process, and finally remove all po files in svn except templates.
My intention of having two po in svn and git was that build (with svn) shouldn't be directly affected even if translator push half-baked work by intention or accident from Pootle (to git). Do you think it is useless or overkill ? As we have some consistency checking on Pootle server implemented by Sayamaindu, I think now the separation have less value ...
/Korakurider
On Thu, Apr 10, 2008 at 9:16 PM, Korakurider korakurider@gmail.com wrote:
On Fri, Apr 11, 2008 at 5:49 AM, Takashi Yamamiya tak@metatoys.org wrote:
Now I'm thinking to add commands into Makefile to automate this process, and finally remove all po files in svn except templates.
My intention of having two po in svn and git was that build (withsvn) shouldn't be directly affected even if translator push half-baked work by intention or accident from Pootle (to git). Do you think it is useless or overkill ?
I understand your concern. But bcause a) Only administrator can commit Pootle's result, a translator can't push half-baked work accidentally. b) A developer can't judge translations. c) Mechanical error is rejected by msgfmt. So I could say it is overkill.
Cheers, - Takashi
On Thu, Apr 10, 2008 at 10:28 PM, Bert Freudenberg bert@freudenbergs.de wrote:
The downloadable files you mentioned are just result of thelatest build and aren't package perfectly ready for use. Those don't contain compiled MOs, so basically you need to place MOs manually.
Actually, the non-dev version should be ready for use. It has MOs.
Aha, I missed the change :-)
The etoys.image has a lang-directory, the etoys-dev.image has a po-directory. Any chance to unifiy them.
We could have both directories in both archives :-)
Why? The one is the source, for developers, the other the compiled result, for users. Shipping POs to users doesn't make sense, and having POs in the dev zip would be redundant.
I agree current packaging is space optimal. But I also thought that it might be confusing to translators but non-developer.
Any chance to include the latest translation-cs form ticket 6704 into the images and Pootle:-)
This is different topic and still needs some work by developers...
I wish there was a way to flag tickets that have a patch waiting for inclusion in the image ... It's too easy to forget about them. We should definitely push the changesets to the update stream (though I have not looked at them in detail, yet). And make a new release soonish.
I still have some remaining work for the ticket (translate symbols for emphasis & alignment with flattering CamelCase. And I have come to think that by addressing #6810, flattering symbols with CamelCase can be handled better). Having bunch of small changes for so many places, it might be risky to push the patches at this stage, but it would be nice if we can release them soon.
/Korakurider
Korakurider schrieb:
Hi, Gerhard.
On 4/10/08, Gerhard Steiner gd.steiner@gmx.at wrote:
Dear all,
The recent situation of etoy-translation is a little bit confusing for me. Is there a chance for some updates to the different images and on Pootle.
http://etoys.laptop.org/src/etoys-dev.zip http://etoys.laptop.org/src/etoys-image-and-pr.zip I downloaded and installed them and pulled all updates up to 1963
The recent images doesn't include the latest changes of translation strings in their pot/po-files (from Feb/Mar). It had to play around with the language-editor to get them somehow available. Is it possible for the developers to update the translations-strings in the images + pootle, in some kind of automatic procedure? I can see only 6 different languages in the language selector in the nav-bar.
The downloadable files you mentioned are just result of thelatest build and aren't package perfectly ready for use. Those don't contain compiled MOs, so basically you need to place MOs manually. Without MOs, Etoys work with in-image translations that we (developers) don't maintain anymore.
There are two reasons why I ask for more frequent updates: 1. I'm impatient :-) I want to translate the latest adapted translation strings (event theatre, ...). It is easier for me if I get additional translation strings in a sequence of smaller portions (25-100) instead of having to wait for one big giant update with 500 additional strings.
2. "New" users which download the "official" zip-images get only outdated german translation. The german translation has been heavily adapted over the last 6 weeks and is now 100% reviewed and checked. I want that new users get a recent translation when they try out etoys. They often don't know how to update the translation in there image or aren't interested to do all the necessary steps (find the po-file, find a tool for compiling, checkpo-File /store mo-file, ...)
Do you have any reason that you don't want work with MOsexternal to image and you want to stick to in-image translations? I believe we don't want to (in usual situation). Here is why:
The Design of legacy-in-image translation dictionary is just onebig original to translation mapping table and functionality is very limited. For example, with the legacy mechanism we can't implement context-aware translation you requested in the recent discussion. Other example is that add-on activity like DrGeoII can have its own translations (with TextDomain of gettext). But for in-image dictionary all translation including add-on ones needs to be unified.
I don't want to work with the in-image translator, but at the moment a gettext-import seems to be the only way to get a recent translation into the dev-image (etoy-dev seems to ignore etoy.mo). That's the only reason why I use the InternalTranslator.
The etoys.image has a lang-directory, the etoys-dev.image has a po-directory. Any chance to unifiy them.
We could have both directories in both archives :-)
I think it would be better if there is only one translation-file/directory. At the it is to easy for a translator to get lost between 5 different different translations for one language (etoy.po on Pootle, etoy.po+etoy.mo local for etoy.image, de.po for etoy-dev.image and the in-image translation etoy). Pleeeeease
The InternalLanguageEditor uses the po-directory for gettext export/import (both etoy+etoy-dev.image).
LanguageEditor still exist as-is for now, and you can import POinto in-image dictionary or export. But the limitation I explained above would affect you. If we introduce context or split big etoys.po into multiple pieces importing will not work.
As described above, all I want is one full and recent german translation:-) Thank you to very much for all the developer effort which has gone and is flowing into the improvement of the translation.
Any chance to include the latest translation-cs form ticket 6704 into the images and Pootle:-)
This is different topic and still needs some work by developers...
Any chance for a time estimation? I got some feedback for the latest german translation ("Hey fine, but there are some things missing"). I want to answer them with "Thank you, missing strings are in progress, please help they will come at dd/mm/yyyy"
kind regards Gerhard Steiner
On Fri, Apr 11, 2008 at 12:56 AM, Gerhard Steiner gd.steiner@gmx.at wrote:
I don't want to work with the in-image translator, but at the moment a gettext-import seems to be the only way to get a recent translation into the dev-image (etoy-dev seems to ignore etoy.mo). That's the only reason why I use the InternalTranslator.
About translation etoys-dev work in the same manner with etoys.image. (Believe me, I am usually working only with dev image) So there might be something wrong with your settings . Note the correct name is NOT etoy.mo BUT etoys.mo.
/Korakurider
etoys-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Gerhard Steiner -
Korakurider -
polishookm -
Takashi Yamamiya