rosettawerks-devel Mailing List for RosettaWerks
Status: Pre-Alpha
Brought to you by:
j_wicks
You can subscribe to this list here.
2002 |
Jan
(13) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|
From: John W. W. <j_...@pa...> - 2002-01-02 05:24:45
|
-----Original Message----- From: Yves S. [mailto:yv...@op...] Sent: Tuesday, January 01, 2002 19:32 To: 'John Wm. Wicks' Subject: RE: Okapi Framework Hi John, This is great feedabck: I haven't done much yet on the word count/segmentation because OSCAR is suppose to do some of this. They'll have a working group were hopefully you should be able to participate. I'll try to kick off some discussion with them later this week. Thanks -yves -----Original Message----- From: John Wm. Wicks [mailto:j_...@pa...] Sent: Tuesday, January 01, 2002 8:18 PM To: 'Yves S.' Subject: RE: Okapi Framework Hello Yves, > -----Original Message----- > From: Yves S. [mailto:yv...@op...] > Sent: Tuesday, January 01, 2002 10:58 > To: j_...@pa... > Subject: RE: Okapi Framework > > > Hello John, > > Okapi itself is relatively new (about 6/7 months), although the ideas > its promotes are much older as you know. We've actually just moved the > project to SourceForge as well. Draft specifications for the Filter > Interface will be available soon as well as several components at > least as beta. With the components will also come part of basic the > base class > library. > > I'll be happy to get your feedback on that work. There are also some > discussion between XLIFF partners about filter interface, so hopefully > things should be able to move forward there. Ok here's some feedback as I go along reading :) The word count example, did you use those actual "abc" corpora. If so, try substituting some real words and see if there's a shift toward more accurate counts. I would hope there is but I've always used wc <:), never did use words as the only mechanism for determining a project scope, it always promoted the very assumption localization companies rally against translation != localization. AT&T always took the numbers I produced based on Document, Dialog, Menu, String and Word counts and converted it to a per word quote that was always two to three times higher than a company that used just words. That's why I came up with the RWQuoter idea which is a rules based quotation utility so you could intelligently compare Apples and Oranges. Well they're both sweet and edible but the Orange you have to peel while the Apple I can just bite into. Well but once you get passed the peeling task you can eat the entire insides of the Orange but with the apple you wind up wasting a lot on the rind... I have a couple of ideas regarding segmentation and word count along the lines of what IBM came up with that involves a rule format that could be embedded like in the Xliff format like they suggest for skeletons so tool vendors could reuse the rules and generate the same counts or at the very least be able to explain why the counts differ. Follows the design pattern Engine/Specification where the Engine, maybe an Okapi component, could parse the rules, based on an Okapi format, to tell the WordCount engine how to behave. John |
From: John W. W. <j_...@pa...> - 2002-01-02 05:24:13
|
-----Original Message----- From: John Wm. Wicks [mailto:j_...@pa...] Sent: Tuesday, January 01, 2002 19:18 To: 'Yves S.' Subject: RE: Okapi Framework Hello Yves, > -----Original Message----- > From: Yves S. [mailto:yv...@op...] > Sent: Tuesday, January 01, 2002 10:58 > To: j_...@pa... > Subject: RE: Okapi Framework > > > Hello John, > > Okapi itself is relatively new (about 6/7 months), although the ideas > its promotes are much older as you know. We've actually just moved the > project to SourceForge as well. Draft specifications for the Filter > Interface will be available soon as well as several > components at least > as beta. With the components will also come part of basic the > base class > library. > > I'll be happy to get your feedback on that work. There are also some > discussion between XLIFF partners about filter interface, so hopefully > things should be able to move forward there. Ok here's some feedback as I go along reading :) The word count example, did you use those actual "abc" corpora. If so, try substituting some real words and see if there's a shift toward more accurate counts. I would hope there is but I've always used wc <:), never did use words as the only mechanism for determining a project scope, it always promoted the very assumption localization companies rally against translation != localization. AT&T always took the numbers I produced based on Document, Dialog, Menu, String and Word counts and converted it to a per word quote that was always two to three times higher than a company that used just words. That's why I came up with the RWQuoter idea which is a rules based quotation utility so you could intelligently compare Apples and Oranges. Well they're both sweet and edible but the Orange you have to peel while the Apple I can just bite into. Well but once you get passed the peeling task you can eat the entire insides of the Orange but with the apple you wind up wasting a lot on the rind... I have a couple of ideas regarding segmentation and word count along the lines of what IBM came up with that involves a rule format that could be embedded like in the Xliff format like they suggest for skeletons so tool vendors could reuse the rules and generate the same counts or at the very least be able to explain why the counts differ. Follows the design pattern Engine/Specification where the Engine, maybe an Okapi component, could parse the rules, based on an Okapi format, to tell the WordCount engine how to behave. John |
From: John W. W. <j_...@pa...> - 2002-01-02 05:23:41
|
-----Original Message----- From: John Wm. Wicks [mailto:j_...@pa...] Sent: Tuesday, January 01, 2002 18:03 To: 'Thierry Sourbier' Subject: RE: Suggestions from j_...@us... Hello Thierry, > -----Original Message----- > From: Thierry Sourbier [mailto:web...@i1...] > Sent: Tuesday, January 01, 2002 13:40 > To: John Wm. Wicks > Subject: Re: Suggestions from j_...@us... > > > > I have been thinking about you're suggestion about Java. > Using C++ doesn't > > preclude cross platform usage but since I'm stripping out > so much code > > anyway do you think the use of Java might generate more > interest from the > > I18n community ?? > > Here are a few arguments to make > > * If I'm not mistaken cross-platform C++, means no-UI. That's > where I'm > wondering on how many people will be using the tool later... > Java while not > the most powerfull language still allows you do have some basic > cross-platform UI. Not really, in my first version zApp a RogueWave product was used and it's a cross platform UI including DOS text mode. It didn't support every conceivable version of Unix but it did work on the major platforms. There is also Zinc and IBM has an API as well. In the OpenSource community there's GTK+ and wxWindows which is the one I was considering on using. > > * Your C++ tool will need to be bundled with the ICU which is > quite big and > can prevent many people with low bandwith from downloading the tool. Yes but Java has the same problem with the JVM and supporting libraries. This suite isn't going to be small, mind you, my first version was well over 45MB with no help or docs if memory serves. I just downloaded the eclipse projects' framework IDE and its a mainly do nothing platform that's 40MB+. I'm hoping to keep the T8n Manager to a minimal download of less than 15MB. > > * Java memory management is better, no more hunting for memory leaks. I use Purify for memory leaks so that hasn't been an issue for me. In OpenSource development it just might be. > > That said you may check out: http://okapi.sourceforge.net/ > (Yves Savourel is > behind it :). That's Windows C++... I talked/typed at him yesterday evening, he remembered my old website "The Midnight Computer Society" and he let me know where Okapi stands currently. Yeah, Yves mentioned that though I didn't go exploring last night and he told me about the ForeignDesk initiative as well... Just when you think you're alone :) When I search for localization nothing like the suite was up there. I should have checked for translation and I might have run into the ForeignDesk product earlier. Thanks for the feedback, this is great stuff... John |
From: John W. W. <j_...@pa...> - 2002-01-02 05:23:19
|
-----Original Message----- From: Thierry Sourbier [mailto:web...@i1...] Sent: Tuesday, January 01, 2002 13:40 To: John Wm. Wicks Subject: Re: Suggestions from j_...@us... > I have been thinking about you're suggestion about Java. Using C++ doesn't > preclude cross platform usage but since I'm stripping out so much code > anyway do you think the use of Java might generate more interest from the > I18n community ?? Here are a few arguments to make * If I'm not mistaken cross-platform C++, means no-UI. That's where I'm wondering on how many people will be using the tool later... Java while not the most powerfull language still allows you do have some basic cross-platform UI. * Your C++ tool will need to be bundled with the ICU which is quite big and can prevent many people with low bandwith from downloading the tool. * Java memory management is better, no more hunting for memory leaks. That said you may check out: http://okapi.sourceforge.net/ (Yves Savourel is behind it :). That's Windows C++... Cheers, Thierry. ----- Original Message ----- From: "John Wm. Wicks" <j_...@pa...> To: "'Thierry Sourbier'" <web...@i1...> Sent: Tuesday, January 01, 2002 4:05 PM Subject: RE: Suggestions from j_...@us... > Hello Thierry, > > > -----Original Message----- > > From: Thierry Sourbier [mailto:web...@i1...] > > Sent: Tuesday, December 25, 2001 01:56 > > To: j_...@us... > > Subject: Re: Suggestions from j_...@us... > > > > > > Hello, > > > > Well you certainly deserve the price for the longest > > description :). A good > > description should fit in a couple of lines so I edited it into: > > > > "Proposal for the development of an open-source Globalization > > Management > > System by John William Wicks. The project is still in its infancy." > > > > Indeed what you are describing is nothing more that what > > other call a "GMS" > > (suite of tools to support the l10n process end-to-end). I > > added the infancy > > comment as indeed currently there is not much documents > > and/or code to spark > > discussion. > > I added the working draft to the site and the previous proposal, though it > isn't of much use except you'll see why I chose C++. Most of the previous > code is C++ though I'm having to strip out all the RogueWave specific stuff > as well as the zApp UI stuff. > > > > > I previously worked in a company that was building such a > > product and I must > > say that the development effort are rather important before you get to > > something interesting. Do you already have some code written? > > What is the > > driver behind your project? I'm also curious about your > > choice of C++ if you > > desire to create an OS independent tool, an arena where Java > > seems a logical > > choice. > > I have been thinking about you're suggestion about Java. Using C++ doesn't > preclude cross platform usage but since I'm stripping out so much code > anyway do you think the use of Java might generate more interest from the > I18n community ?? I have a couple of other developers, C++, interested in > helping out but until I get the requirements done there isn't much coding to > do. If I go with Java then I might have to get someone else to help out with > the proposal/requirements. > > > > > I think there is indeed a need for an open-source GMS based > > on existing > > and/or upcoming standarts (Xliff, TMX, OTX, etc...). Please > > keep me posted > > on your progress. > > I went exploring again on the OpenTag site and ran across the Okapi > Framework page. It jogged my memory somewhat, wasn't this about at the same > point in 96/97 ?? I plan on using the same formats suggested there but if > the framework isn't going anywhere then I'll drop the API. You said Yves is > maintaining the OpenTag site, I guess I should try contacting him about the > status of the framework. > > Thanks for any information you might provide... > > John > |
From: John W. W. <j_...@pa...> - 2002-01-02 05:22:52
|
-----Original Message----- From: John Wm. Wicks [mailto:j_...@pa...] Sent: Tuesday, January 01, 2002 11:49 To: 'Yves S.' Subject: RE: Okapi Framework Hello Yves, > -----Original Message----- > From: Yves S. [mailto:yv...@op...] > Sent: Tuesday, January 01, 2002 10:58 > To: j_...@pa... > Subject: RE: Okapi Framework > > > Hello John, > > Great to hear from you. I remember your name from long time ago (very > long it seems): you had something call "the midnight > computing society" > or something like that going on. > I loved that name. Yep the Midnight Computer Society. Still have the domain but the Web Company I was working for went belly up and I'm working on getting it hosted again while finding a new job :)... I think I even interviewed with you for a job at ILE in Boulder if I'm not mistaken. Kinda glad I didn't accept the offer, since ILE got sold. At least I'm warm and outta work in Sacramento rather than cold in Boulder. How have you been ?? I see the new book so things must be going pretty well. > > Thanks for the information about RosettaWerks. It seems you > have a nice > suite in mind. It looks very complete. This is also a complex > and large > project you are taking on. I hope you will be able to make significant > progress quickly. Hopefully some of Okapi's components will be able to > help. I have been discussing this with Thierry Sourbier, since I posted this on I18ngurus. Since I did most of the previous development in C++ I was going to work as a C++ project this time as well, but Thierry pointed out that Java might be a better fit. I'm not really a Java developer but I ran across a OpenSource project called Eclipse and if I go with Java I might be able to steal/reuse much of this platform... > you want to follow as well: many translation customers are promoting > XLIFF now and some even send their material directly in XLIFF. It > includes a lot of feature for versioning, review changes, etc. so it > should fit easily in RosettaWerks' workflow. I was planning on incorporating that format, has anyone come up with a solution for reuse of the UI coordinates yet that you know of. I remember a thread on OpenTag.org about this but forget if this was going to be part of the specification. > I'll be happy to get your feedback on that work. There are also some > discussion between XLIFF partners about filter interface, so hopefully > things should be able to move forward there. I'll have a look see then... > > Several other aspects of Okapi are at a stand-still because we are > waiting to see how/if LISA' OSCAR will be moving forward on those > issues: there is for example a word-count and a segmentation working > group that is suppose to be activated soon. Same goes for ITS' efforts > which are also linked to Okapi. There is also the W3C i18n Group which > is resetting its goals at the Washington workshop on Feb-1, we may end > up working there on some of those localization aspects as well. Isn't IBM on the OSCAR committee, they have a wonderful start on the segmentation issue on their developerWorks site. It's Java but the framework is extensible and Rules based. > > That is the current status regarding Okapi. Hopefully it should be a > good help to develop RosettaWerks and other open-source > suites (I think > ForeignDesk is also open-source now). Yeah I just saw that as well... > Have a happy year 2002. > > Kind Regards, > -Yves Savourel > Same to you... John |
From: John W. W. <j_...@pa...> - 2002-01-02 05:22:23
|
-----Original Message----- From: Yves S. [mailto:yv...@op...] Sent: Tuesday, January 01, 2002 10:58 To: j_...@pa... Subject: RE: Okapi Framework Hello John, Great to hear from you. I remember your name from long time ago (very long it seems): you had something call "the midnight computing society" or something like that going on. I loved that name. Thanks for the information about RosettaWerks. It seems you have a nice suite in mind. It looks very complete. This is also a complex and large project you are taking on. I hope you will be able to make significant progress quickly. Hopefully some of Okapi's components will be able to help. > Back in 96 the only TMX like standard I knew of was OpenTag from ILE. > I had thought that OpenTag had gone the way of the dodo but found the > link to opentag.com. OpenTag was not maintained by International Communication when they bought ILE, then LionBridge didn't revived it either. But it did lives through opentag.com all that time and has been used by various in-house and commercial tools (i.e. SDLX, Trans Suite 2000, Sykes' tools, etc.), lately it was used at the base for XLIFF. That is probably the direction you want to follow as well: many translation customers are promoting XLIFF now and some even send their material directly in XLIFF. It includes a lot of feature for versioning, review changes, etc. so it should fit easily in RosettaWerks' workflow. > I'd like to incorporate some of the Okapi framework into the project > if it's still moving forward I believe the framework was in much the > same state in 96/97 but I haven't been doing localization work since > early 97 so I'm a little outta touch. Okapi itself is relatively new (about 6/7 months), although the ideas its promotes are much older as you know. We've actually just moved the project to SourceForge as well. Draft specifications for the Filter Interface will be available soon as well as several components at least as beta. With the components will also come part of basic the base class library. I'll be happy to get your feedback on that work. There are also some discussion between XLIFF partners about filter interface, so hopefully things should be able to move forward there. Several other aspects of Okapi are at a stand-still because we are waiting to see how/if LISA' OSCAR will be moving forward on those issues: there is for example a word-count and a segmentation working group that is suppose to be activated soon. Same goes for ITS' efforts which are also linked to Okapi. There is also the W3C i18n Group which is resetting its goals at the Washington workshop on Feb-1, we may end up working there on some of those localization aspects as well. That is the current status regarding Okapi. Hopefully it should be a good help to develop RosettaWerks and other open-source suites (I think ForeignDesk is also open-source now). Have a happy year 2002. Kind Regards, -Yves Savourel |
From: John W. W. <j_...@pa...> - 2002-01-02 05:21:31
|
-----Original Message----- From: John Wm. Wicks [mailto:j_...@pa...] Sent: Tuesday, January 01, 2002 09:57 To: 'Thierry Sourbier' Subject: RE: Suggestions from j_...@us... Hello Thierry, > -----Original Message----- > I previously worked in a company that was building such a > product and I must > say that the development effort are rather important before you get to > something interesting. Do you already have some code written? > What is the > driver behind your project? I'm also curious about your > choice of C++ if you > desire to create an OS independent tool, an arena where Java > seems a logical > choice. After sending my last message I went exploring and found an interesting Java "platform" that would work extremely well as the basis for the suite. It's an OpenSource initiative called eclipse and it's got a plug in type architecture that looks promising. Boy more choices... Java is still a bit slow from my perspective though. Oh yeah, Happy New Year... John |
From: John W. W. <j_...@pa...> - 2002-01-02 05:20:51
|
-----Original Message----- From: John Wm. Wicks [mailto:j_...@pa...] Sent: Tuesday, January 01, 2002 07:05 To: 'Thierry Sourbier' Subject: RE: Suggestions from j_...@us... Hello Thierry, > -----Original Message----- > From: Thierry Sourbier [mailto:web...@i1...] > Sent: Tuesday, December 25, 2001 01:56 > To: j_...@us... > Subject: Re: Suggestions from j_...@us... > > > Hello, > > Well you certainly deserve the price for the longest > description :). A good > description should fit in a couple of lines so I edited it into: > > "Proposal for the development of an open-source Globalization > Management > System by John William Wicks. The project is still in its infancy." > > Indeed what you are describing is nothing more that what > other call a "GMS" > (suite of tools to support the l10n process end-to-end). I > added the infancy > comment as indeed currently there is not much documents > and/or code to spark > discussion. I added the working draft to the site and the previous proposal, though it isn't of much use except you'll see why I chose C++. Most of the previous code is C++ though I'm having to strip out all the RogueWave specific stuff as well as the zApp UI stuff. > > I previously worked in a company that was building such a > product and I must > say that the development effort are rather important before you get to > something interesting. Do you already have some code written? > What is the > driver behind your project? I'm also curious about your > choice of C++ if you > desire to create an OS independent tool, an arena where Java > seems a logical > choice. I have been thinking about you're suggestion about Java. Using C++ doesn't preclude cross platform usage but since I'm stripping out so much code anyway do you think the use of Java might generate more interest from the I18n community ?? I have a couple of other developers, C++, interested in helping out but until I get the requirements done there isn't much coding to do. If I go with Java then I might have to get someone else to help out with the proposal/requirements. > > I think there is indeed a need for an open-source GMS based > on existing > and/or upcoming standarts (Xliff, TMX, OTX, etc...). Please > keep me posted > on your progress. I went exploring again on the OpenTag site and ran across the Okapi Framework page. It jogged my memory somewhat, wasn't this about at the same point in 96/97 ?? I plan on using the same formats suggested there but if the framework isn't going anywhere then I'll drop the API. You said Yves is maintaining the OpenTag site, I guess I should try contacting him about the status of the framework. Thanks for any information you might provide... John |
From: John W. W. <j_...@pa...> - 2002-01-02 05:20:06
|
-----Original Message----- From: John Wm. Wicks [mailto:j_...@pa...] Sent: Wednesday, December 26, 2001 01:38 To: 'Thierry Sourbier' Subject: RE: Suggestions from j_...@us... Hello Thierry, > -----Original Message----- > From: Thierry Sourbier [mailto:web...@i1...] > Sent: Wednesday, December 26, 2001 01:34 > To: John Wm. Wicks > Subject: Re: Suggestions from j_...@us... > > > > I'm currently working over the old proposal and > > requirements for discussion. I hope to get the proposal and > some of the > > requirements squared away before the end of the holidays > > Lots as changed since 96 :). I don't know how much of a > development workfoce > you'll have but If I were you, I would start with some very simple > requirements such as handling text, HTML and XML formats only > to trigger > people's interest and then move on to more complex things. > > > Back in 96 the only TMX like standard I knew of was OpenTag > from ILE. I > had thought that > > OpenTag had gone the way of the dodo but found the link to > opentag.com. I > > haven't gone over the site yet but is OpenTag still around > or has it been > > absorbed... > > Funny, back in 96 I was working at ILE :). Opentag still > exist but XLIFF is > probably aimed at replacing it. Yves Savourel (the main actor behind > OpenTag) is still maintaining Opentag.com and recently published an > excellent book on XML i18n/l10n. If you were still around in 97 we may have met then. I almost went to work for ILE, came out to Boulder and went through the whole facility. I saw the book advert might have to check it out, the opportunity to work with Yves one one of the reasons I considered working for ILE. Just something during the interview process struck me funny and I decided not to accept the employment offer. Looking back now, I'm glad I didn't move out there. John |
From: John W. W. <j_...@pa...> - 2002-01-02 05:19:35
|
-----Original Message----- From: Thierry Sourbier [mailto:web...@i1...] Sent: Wednesday, December 26, 2001 01:34 To: John Wm. Wicks Subject: Re: Suggestions from j_...@us... > I'm currently working over the old proposal and > requirements for discussion. I hope to get the proposal and some of the > requirements squared away before the end of the holidays Lots as changed since 96 :). I don't know how much of a development workfoce you'll have but If I were you, I would start with some very simple requirements such as handling text, HTML and XML formats only to trigger people's interest and then move on to more complex things. > Back in 96 the only TMX like standard I knew of was OpenTag from ILE. I had thought that > OpenTag had gone the way of the dodo but found the link to opentag.com. I > haven't gone over the site yet but is OpenTag still around or has it been > absorbed... Funny, back in 96 I was working at ILE :). Opentag still exist but XLIFF is probably aimed at replacing it. Yves Savourel (the main actor behind OpenTag) is still maintaining Opentag.com and recently published an excellent book on XML i18n/l10n. Cheers, Thierry. |
From: John W. W. <j_...@pa...> - 2002-01-02 05:19:06
|
-----Original Message----- From: John Wm. Wicks [mailto:j_...@pa...] Sent: Tuesday, December 25, 2001 09:22 To: 'Thierry Sourbier' Subject: RE: Suggestions from j_...@us... Hello Thierry, > -----Original Message----- > From: Thierry Sourbier [mailto:web...@i1...] > Sent: Tuesday, December 25, 2001 01:56 > To: j_...@us... > Subject: Re: Suggestions from j_...@us... > > > Hello, > > Well you certainly deserve the price for the longest > description :). A good > description should fit in a couple of lines so I edited it into: > > "Proposal for the development of an open-source Globalization > Management > System by John William Wicks. The project is still in its infancy." Just a little carried away wouldn't you say :)... > > Indeed what you are describing is nothing more that what > other call a "GMS" > (suite of tools to support the l10n process end-to-end). I > added the infancy > comment as indeed currently there is not much documents > and/or code to spark > discussion. > > I previously worked in a company that was building such a > product and I must > say that the development effort are rather important before you get to > something interesting. Do you already have some code written? > What is the > driver behind your project? I'm also curious about your > choice of C++ if you > desire to create an OS independent tool, an arena where Java > seems a logical > choice. I have almost the complete suite of code but it's from circa 95/96 when I first embarked on the idea and the code uses ZApp and other utilities not fit for OpenSource. Course I never did get around to completing it and in 97 I got out of the L10N arena when AT&T Business Translations/Lucent moved along. I was going through some old projects recently and thought I'd revive it in OpenSource. I'm currently working over the old proposal and requirements for discussion. I hope to get the proposal and some of the requirements squared away before the end of the holidays. Back in 96 the only TMX like standard I knew of was OpenTag from ILE. I had thought that OpenTag had gone the way of the dodo but found the link to opentag.com. I haven't gone over the site yet but is OpenTag still around or has it been absorbed... As for the C++ question the language can be used on many platforms and I guess I've never bought in to the "Write Once" mantra of Java though I suppose it's matured from my 97 adventures with it... > > I think there is indeed a need for an open-source GMS based > on existing > and/or upcoming standarts (Xliff, TMX, OTX, etc...). Please > keep me posted > on your progress. > > Happy Chrismass! > > Cheers, > Thierry. Thanks again for the edit and I hope to generate enough interest to keep this thing going... I'll keep you updated.... Happy Holidays, John |
From: John W. W. <j_...@pa...> - 2002-01-02 05:14:26
|
-----Original Message----- =46rom: Thierry Sourbier [mailto:web...@i1...] Sent: Tuesday, December 25, 2001 01:56 To: j_...@us... Subject: Re: Suggestions from j_...@us... Hello, Well you certainly deserve the price for the longest description :). = A good description should fit in a couple of lines so I edited it into: "Proposal for the development of an open-source Globalization Managem= ent System by John William Wicks. The project is still in its infancy." Indeed what you are describing is nothing more that what other call a= "GMS" (suite of tools to support the l10n process end-to-end). I added the = infancy comment as indeed currently there is not much documents and/or code t= o spark discussion. I previously worked in a company that was building such a product and= I must say that the development effort are rather important before you get t= o something interesting. Do you already have some code written? What is= the driver behind your project? I'm also curious about your choice of C++= if you desire to create an OS independent tool, an arena where Java seems a = logical choice. I think there is indeed a need for an open-source GMS based on existi= ng and/or upcoming standarts (Xliff, TMX, OTX, etc...). Please keep me p= osted on your progress. Happy Chrismass! Cheers, Thierry. ----- Original Message ----- =46rom: <i1...@se...> To: <web...@i1...> Sent: Tuesday, December 25, 2001 4:06 AM Subject: Suggestions from j_...@us... > I just submitted a link for OpenSource Globalization Suite - Rosett= aWerks Initiative but wanted to edit it after looking it over and it got dou= bled up. > > Here's a better description... > > Announcing a proposal for the development of a suite of programs th= at deal with the localization process. Each of the components in the suite de= als with certain problems endemic to the localization process. No single = program can deal with all problems, but if specifically targeted, a suite of programs can. There are several segments involved in a localization project;<BR> > =B7 The client, this may be an internal division within a company o= r it may be an ISV. Users in this segment are generally involved in developmen= t and project management of the original software. Generally, the internationalization of the original software is handled in this segment.<BR> > =B7 The vendor, this may be an internal division or staff member wi= thin a company or it may be an outside localization company. Users in this s= egment are involved in localization and project management of the localized software. In some cases, where the original software isn’t prep= ared for localization, an internationalization project is also managed in = this segment.<BR> > =B7 The translator, this may include in-house employees or outside contractors. Users in this segment are concerned with linguistics and terminology issues.<BR> > As the volume of materials increase and more and more clients requi= re simultaneous release of localization projects, the localization team = must rapidly respond to changing demands while delivering a quality produc= t. To do this the localization team needs an edge, this suite of programs i= s designed to be that edge. Each component in the suite is targeted to = meet the specific needs of the segments mentioned above, while maintaining synergy between the team members.<BR><BR> > Come help out, view our progress and post your feature requests. > > |
From: John W. W. <j_...@pa...> - 2002-01-02 05:14:02
|
Announcing a proposal for the development of a suite of programs that deal with the localization process. Each of the components in the suite deals with certain problems endemic to the localization process. No single program can deal with all problems, but if specifically targeted, a suite of programs can. There are several segments involved in a localization project. The client, this may be an internal division within a company or it may be an ISV. Users in this segment are generally involved in development and project management of the original software. Generally, the internationalization of the original software is handled in this segment. The vendor, this may be an internal division or staff member within a company or it may be an outside localization company. Users in this segment are involved in localization and project management of the localized software. In some cases, where the original software isn’t prepared for localization, an internationalization project is also managed in this segment. The translator, this may include in-house employees or outside contractors. Users in this segment are concerned with linguistics and terminology issues. As the volume of materials increase and more and more clients require simultaneous release of localization projects, the localization team must rapidly respond to changing demands while delivering a quality product. To do this the localization team needs an edge, this suite of programs is designed to be that edge. Each component in the suite is targeted to meet the specific needs of the segments mentioned above, while maintaining synergy between the team members. The working draft has been posted on the RosettaWerks project site on SourceForge at http://sourceforge.net/docman/display_doc.php?docid=8461&group_id=40243 John |