g11ntoolkit-developer Mailing List for Globalization Tool Kit
Brought to you by:
billrich
You can subscribe to this list here.
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(4) |
---|
From: Raymond M. <bio...@ya...> - 2005-12-13 17:30:24
|
Hi Bill, > I am sorry that I have taken so long to respond. I am changing my DNS routings > and my hosting service and I guess it is playing havoc with my mail and my ability > to post to this list. No problem. > I agree that the XLIFF Editor should be packaged separately. The editor depends > on classes in the G11NToolKit but the toolkit does not depend on the editor. Okay, good. That makes the base toolkit that much smaller. Implementers will be more inclined to use it if it is smaller. > What other parts of the toolkit are you thinking may need to be separated? Not exactly sure at present. The XLIFF DB and DB update are shown as optional in the process diagram, are they possibilities? > You have a concern about overlap in function between omegat and the toolkit. > Do you need finer granularity in the toolkit classes or are you more concerned > at a higher level with overall function. If you need a finer granularity we can > probably just factor the classes to see where we can split them. This makes > more classes but may make using the toolkit easier. Bare with me, I'm still looking at the toolkit mostly from a top level view right now. I'll have to comment about granularity at some later time. What I do think would be interesting is to have a general mechanism to pipeline the overall localization/translation from end to end. Given that there is already a stock process in place it could be possible to replace components with extended versions or altogether different ones. These replacements could be dependent upon some form of pipeline definitions that will enable I/O in between the component connections or rerouting through user components/pipelines. Perhaps this could lead to having a number of pre-made replacement components and pipelines that can be mixed and matched for more flexibility and particular end purposes (localization, translation, authoring, ?) Maybe this is a lot of work to implement in the short term, might be something to consider as part of the toolkit's future evolution. Don't know if you have seen it, but gstreamer (http://gstreamer.freedesktop.org) is a good example of a pipelining application if you want to look at it. Cheers. Raymond __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
From: Bill R. <bi...@wi...> - 2005-12-13 06:37:33
|
Hi Raymond, I am sorry that I have taken so long to respond. I am changing my DNS = routings and my hosting service and I guess it is playing havoc with my = mail and my ability to post to this list. I agree that the XLIFF Editor should be packaged separately. The editor = depends on classes in the G11NToolKit but the toolkit does not depend on = the editor. As for the rest of the toolkit, I suppose that the pseudoxlator and = xlclassname utilities could be separated from the rest of the classes = since again they depend on classes in the toolkit but the toolkit does = not depend on them. The only exception to this is that the toolkit = process control in the Ant files uses the xlclassname utility in its = normal detok processing for Java LRB files. This may cause a little = issue but with separate jar files it should not be a major issue. The rest of the class structure pretty much needs to stay together in a = single jar since it represents the main classes of the toolkit. What other parts of the toolkit are you thinking may need to be = separated? You have a concern about overlap in function between omegat and the = toolkit. Do you need finer granularity in the toolkit classes or are you = more concerned at a higher level with overall function. If you need a = finer granularity we can probably just factor the classes to see where = we can split them. This makes more classes but may make using the = toolkit easier. Thanks. Bill |
From: Bill R. <bi...@wi...> - 2005-12-10 16:03:48
|
Please ignore this message. I have some problem that is preventing me = from posting to this list and am trying to solve it. Sorry for the = disruption. Bill |
From: Raymond M. <bio...@ya...> - 2005-12-06 21:52:28
|
Hi Bill and all, In continuance of my feature request for the toolkit to broken up into more components. Breaking out the XLIFF editor should be an easy task. Create separate jars for the main toolkit and the editor. Put the classpath to the toolkit jar in the editors jar manifest. Done. Perhaps provide both full toolkit jar (with XLIFF editor) and separate jars. What other components in the toolkit can be considered more on the auxiliary side or would be better suited packaged separately? A central consideration for me working on development for the omegat CAT tool is how to incorporate g11ntoolkit into it without having code that overlaps in functionality with existing code or future code. For instance, omegat has a number of its own file filters just as does the toolkit. A few of these overlap, so a solution is required. The question is then whether to augment the filters in the toolkit, separate them out to later be augmented, or layer a specific apps filters on top of the toolkit's own ones. I might be getting ahead of myself though, still need to look at things in the toolkit more closely. Cheers. Raymond __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |