UserMessage & Localization

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

UserMessage & Localization

andre
Hi all,

After researching services for crowdsourced or distributed localization (transifex, crowdin, wordbee, onesky, cloudwords, etc), I now wonder how to extract all UserMessages from a Smalltalk image to aggregate them in a PO, XLIFF, Android XML or other format file for upload.

Has anyone done this before? How would one scan the image for literals and message sends associated with UserMessage in order to collect the key, catalog ID and defaultString ? So, basically this would mean finding all occurrences of the pattern:

        (#messageID << #catalogID >> 'Default String‘)

and all instances of literal arrays used for canvases (windowSpec). I’m really bad at the pattern search utility, but am guessing this would be the way to go. How would the search expression look like?

Or am I completely missing the obvious?

Thanks in advance for any hints.

Andre


(P.S: Sorry for the double post, sender was wrong. Please delete previous message)
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: UserMessage & Localization

Randy Coulman
Andre,

Take a look at the ExtraCatalogs and ExtraCatalogsTools packages in the public Store repository.  These have support for XLIFF and probably do something close to what you want.


Randy

On Tue, Apr 14, 2015 at 12:18 PM, andre <[hidden email]> wrote:
Hi all,

After researching services for crowdsourced or distributed localization (transifex, crowdin, wordbee, onesky, cloudwords, etc), I now wonder how to extract all UserMessages from a Smalltalk image to aggregate them in a PO, XLIFF, Android XML or other format file for upload.

Has anyone done this before? How would one scan the image for literals and message sends associated with UserMessage in order to collect the key, catalog ID and defaultString ? So, basically this would mean finding all occurrences of the pattern:

        (#messageID << #catalogID >> 'Default String‘)

and all instances of literal arrays used for canvases (windowSpec). I’m really bad at the pattern search utility, but am guessing this would be the way to go. How would the search expression look like?

Or am I completely missing the obvious?

Thanks in advance for any hints.

Andre


(P.S: Sorry for the double post, sender was wrong. Please delete previous message)
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc



--
Randy Coulman
Email: [hidden email]
Home: http://randycoulman.com
Twitter: @randycoulman      GitHub: randycoulman

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: UserMessage & Localization

andre
Randy, Karsten,

Thanks a lot. UserMessageExtractor is exactly what I was looking for. 

The Internationalizer parcel also looks promising.

Andre

--
Am 14.04.2015 um 21:30 schrieb Randy Coulman <[hidden email]>:

Andre,

Take a look at the ExtraCatalogs and ExtraCatalogsTools packages in the public Store repository.  These have support for XLIFF and probably do something close to what you want.


Randy


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: UserMessage & Localization

Maarten Mostert-2
Hi Randy,

I am not at that but I read in your blog that your implementation for user messages is all in memory.

What is the bottom reason / benefit in terms of performance, is that significant to the point that is improves the user experience.

Regards,

@+Maarten,



Le 15 avr. 2015 à 15:24, andre <[hidden email]> a écrit :

Randy, Karsten,

Thanks a lot. UserMessageExtractor is exactly what I was looking for. 

The Internationalizer parcel also looks promising.

Andre

--
Am 14.04.2015 um 21:30 schrieb Randy Coulman <[hidden email]>:

Andre,

Take a look at the ExtraCatalogs and ExtraCatalogsTools packages in the public Store repository.  These have support for XLIFF and probably do something close to what you want.


Randy

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: UserMessage & Localization

Randy Coulman
Hi, Maarten,

I didn't write ExtraCatalogs originally - that was Travis Griggs.  I'm not sure of his reasons for making it in-memory.

But I can imagine that having the whole catalog available in memory means that there won't be any pauses when displaying pages in your application, because the message catalogs won't have to be loaded from the disk first.

It wouldn't be difficult to have different SimpleMessageCatalogs for different parts of your application and then only load the relevant catalogs when the user navigates to that part and unloading them when they leave.  That way, you wouldn't be paying the price of having all of the translations in memory at once.

Does this answer your question?

Thanks,
Randy


On Wed, Apr 15, 2015 at 11:02 PM, Maarten Mostert <[hidden email]> wrote:
Hi Randy,

I am not at that but I read in your blog that your implementation for user messages is all in memory.

What is the bottom reason / benefit in terms of performance, is that significant to the point that is improves the user experience.

Regards,

@+Maarten,



Le 15 avr. 2015 à 15:24, andre <[hidden email]> a écrit :

Randy, Karsten,

Thanks a lot. UserMessageExtractor is exactly what I was looking for. 

The Internationalizer parcel also looks promising.

Andre

--
Am 14.04.2015 um 21:30 schrieb Randy Coulman <[hidden email]>:

Andre,

Take a look at the ExtraCatalogs and ExtraCatalogsTools packages in the public Store repository.  These have support for XLIFF and probably do something close to what you want.


Randy

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc




--
Randy Coulman
Email: [hidden email]
Home: http://randycoulman.com
Twitter: @randycoulman      GitHub: randycoulman

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: UserMessage & Localization

Karsten Kusche
Hi Marten,

some weeks ago we implemented a MessageCatalog that would store its translations in Code. That also keeps the translations in memory, but most importantly it allows us to publish our translations to Store together with the rest of the project. 

Kind Regards
Karsten



-- 
Karsten Kusche - Dipl. Inf. (FH) - [hidden email]
Georg Heeg eK - Köthen
Handelsregister: Amtsgericht Dortmund A 12812 

Am 16. April 2015 bei 16:40:06, Randy Coulman ([hidden email]) schrieb:

Hi, Maarten,

I didn't write ExtraCatalogs originally - that was Travis Griggs.  I'm not sure of his reasons for making it in-memory.

But I can imagine that having the whole catalog available in memory means that there won't be any pauses when displaying pages in your application, because the message catalogs won't have to be loaded from the disk first.

It wouldn't be difficult to have different SimpleMessageCatalogs for different parts of your application and then only load the relevant catalogs when the user navigates to that part and unloading them when they leave.  That way, you wouldn't be paying the price of having all of the translations in memory at once.

Does this answer your question?

Thanks,
Randy


On Wed, Apr 15, 2015 at 11:02 PM, Maarten Mostert <[hidden email]> wrote:
Hi Randy,

I am not at that but I read in your blog that your implementation for user messages is all in memory.

What is the bottom reason / benefit in terms of performance, is that significant to the point that is improves the user experience.

Regards,

@+Maarten,



Le 15 avr. 2015 à 15:24, andre <[hidden email]> a écrit :

Randy, Karsten,

Thanks a lot. UserMessageExtractor is exactly what I was looking for. 

The Internationalizer parcel also looks promising.

Andre

--
Am 14.04.2015 um 21:30 schrieb Randy Coulman <[hidden email]>:

Andre,

Take a look at the ExtraCatalogs and ExtraCatalogsTools packages in the public Store repository.  These have support for XLIFF and probably do something close to what you want.


Randy

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc




--
Randy Coulman
Email: [hidden email]
Home: http://randycoulman.com
Twitter: @randycoulman      GitHub: randycoulman
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: UserMessage & Localization

Thomas Brodt-2
That's what we also did long ago. We have MessageCatalog classes that resolve UserMessages to Strings. We also have the benefit of having Store for version control.

There sometimes was a remarkable delay to resolve messages from file catalogs. Especially if you opened a context menu with many messages it could lead to a remarkable pause before the menu finally opened after the mouse click. This was quite irritating.

Thomas

Am 16.04.2015 um 16:50 schrieb Karsten Kusche:
Hi Marten,

some weeks ago we implemented a MessageCatalog that would store its translations in Code. That also keeps the translations in memory, but most importantly it allows us to publish our translations to Store together with the rest of the project. 

Kind Regards
Karsten



-- 
Karsten Kusche - Dipl. Inf. (FH) - [hidden email]
Georg Heeg eK - Köthen
Handelsregister: Amtsgericht Dortmund A 12812 

Am 16. April 2015 bei 16:40:06, Randy Coulman ([hidden email]) schrieb:

Hi, Maarten,

I didn't write ExtraCatalogs originally - that was Travis Griggs.  I'm not sure of his reasons for making it in-memory.

But I can imagine that having the whole catalog available in memory means that there won't be any pauses when displaying pages in your application, because the message catalogs won't have to be loaded from the disk first.

It wouldn't be difficult to have different SimpleMessageCatalogs for different parts of your application and then only load the relevant catalogs when the user navigates to that part and unloading them when they leave.  That way, you wouldn't be paying the price of having all of the translations in memory at once.

Does this answer your question?

Thanks,
Randy


On Wed, Apr 15, 2015 at 11:02 PM, Maarten Mostert <[hidden email]> wrote:
Hi Randy,

I am not at that but I read in your blog that your implementation for user messages is all in memory.

What is the bottom reason / benefit in terms of performance, is that significant to the point that is improves the user experience.

Regards,

@+Maarten,



Le 15 avr. 2015 à 15:24, andre <[hidden email]> a écrit :

Randy, Karsten,

Thanks a lot. UserMessageExtractor is exactly what I was looking for. 

The Internationalizer parcel also looks promising.

Andre

--
Am 14.04.2015 um 21:30 schrieb Randy Coulman <[hidden email]>:

Andre,

Take a look at the ExtraCatalogs and ExtraCatalogsTools packages in the public Store repository.  These have support for XLIFF and probably do something close to what you want.


Randy

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc




--
Randy Coulman
Email: [hidden email]
Home: http://randycoulman.com
Twitter: @randycoulman      GitHub: randycoulman
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc