Geez - I gotta figure out what I'm doing to mess this up.

So, let me try again.

- It sounds like you have the ability to do the abbreviation support in
terms of associating them with a particular phrase.

- String length cap: Samuel is right about the medical/cellphone
applications.  However, for deeply embedded applications using
non-Windows/Linux GUIs the cap is not in terms of characters, but in
pixels.  You have to think in terms of pixels because that is how the
fields are typically specified and also the font may change when
language is changed.  For instance, it is common that when rendering
German the strings get longer and but the number of characters may be
the same because we'll choose to use a smaller font.  Also, it is common
practice to specify a field in terms of "English + 30%" and then choose
smaller fonts for those languages which typically result in longer
strings. So, the application may need to be...what...agile in terms of
knowing what font will be used by language.  

- Screen viewer: I was just thinking of having a bitmap of the screen,
not have an entire GUI library to show the screen.  The application
would keep a copy of the bitmap, and the app could display it to the
translator when working in a particular context (medical device A as
opposed to cellphone device B).  The customer would have to supply the
bitmaps and the pixel locations of the various fields.  I don't think
that it would be too hard to render the text into the bitmap at a
specified location?  Seems like something that could be done with a
command line based graphics application.  My buddy was telling me about
one, but I forget its name.  I think GIMP now has some of that
functionality.  Another way of checking this non-visually would be to
calculate the pixel height/width of the string based on the font and see
if it would fit into box dimensions specified by the customer.  At my
company we have actually developed the GUI portion of our device to run
in Windows using the target GUI library.  We then give the translation
vendor the application code, and build tools.  They do the translation,
put it into the code, rebuild and verify that the translation fits.
We'd really like to get away from having to buy build tools for our
translation vendors.

- String/word/abbrev usage: I was thinking of attaching records directly
to the translation which would indicate where it was used by
project/screen/field.  Sure, you could put it in a comments field, but
that seems like it would be open to misunderstandings about what to put
in there and what format it should be in.  I suppose the pootle GUI
could do the formatting for you, but it would still be subject to
editing mistakes.

Well, I may be trying to graft on some requirements to pootle that it
just wasn't intended for.  Thanks again for taking a look at this.

Regards,
 
Paul E. Ourada
Principal Software Engineer
Covidien
Energy-based Devices
5920 Longbow Dr
Boulder, CO 80301
USA
Office: 303-581-6940
[EMAIL PROTECTED]
http://www.covidien.com
 

> -----Original Message-----
> From: Ourada, Paul
> Sent: Tuesday, October 23, 2007 8:52 AM
> To: Samuel Murray; translate-pootle
> Subject: RE: [translate-pootle] Embedded Systems Support? Or the rest
of
> the story...
> 
> Hi Dwayn and Samuel --
> 
> Thanks for your kind responses.  You are not the first to tell me to
slow
> down and really say what I mean.  My wife, if she were privy to this
> conversation, would be saying: See?? I'm not the *only* one who's
> complaining about this. :)
> 
> So, let me try again.
> 
> - It sounds like you have the ability to do the abbreviation support
in
> terms of associating them with a particular phrase.
> 
> - String length cap: What I was trying to say is that it would be nice
to
> be able to allow a translation vendor access to the screens that the
> strings will appear in, so that they can visually verify that the
> translated strings will fit.  There are two criteria here, I think.
> 
> - Keeping track of where a string is used.
> 
> Regards,
> 
> Paul E. Ourada
> Principal Software Engineer
> Covidien
> Energy-based Devices
> 5920 Longbow Dr
> Boulder, CO 80301
> USA
> Office: 303-581-6940
> [EMAIL PROTECTED]
> http://www.covidien.com
> 
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
[mailto:translate-
> > [EMAIL PROTECTED] On Behalf Of Samuel Murray
> > Sent: Tuesday, October 23, 2007 6:14 AM
> > To: translate-pootle
> > Subject: Re: [translate-pootle] Embedded Systems Support? Or the
rest of
> > the story...
> >
> >
> > G'day Dwayne and Paul
> >
> > I'm not a programmer or a Pootle expert, but here are my thoughts.
> > Paul's introductory e-mail was a little cryptic for me, but I hope
> > Dwayne's interpretation of it is correct.  If not, please tell.
> >
> > Dwayne Bailey het geskryf:
> >
> > > On Mon, 2007-10-22 at 17:51 -0400, Ourada, Paul wrote:
> >
> > >> - abbreviation support: in embedded systems we tend to have
> > >> fixed text fields, so translators often have to come up with
> > >> abbreviations in various languages.
> >
> > > I assume what you really mean is that the system should limit the
> entry
> > > to N characters?  We don't do that, its never emerged as a
requirement
> > > in the non-embedded world, so its never been coded.
> >
> > I have encountered this in the translation of user interfaces for
cell
> > phones and medical auxiliary equipment.  I have also had this in the
> > mobile edition of Opera web browser.  There is a limit on the text
> > length and it would be great if a Pootle user can be alerted of it.
> >
> > The Pootle UI is HTML/JavaScript, and there are free JavaScript
scripts
> > that count the characters in a text box in real time.  The character
> > count of the source text can be handled by pocount, not?  So all you
> > need is some kind of comparison, and perhaps a counter box that
turns
> > red if the one exceeds the other.
> >
> > As for pofilter... isn't there a way to check the msgid char length
> > against the msgstr char length?  Dwayne?  Can a smart regex do this
with
> > the existing pofilter?
> >
> > >> - about those fixed fields: font and screen support: it would
> > >> be really really nice to be able to hand a list of words/phrases
to
> be
> > xlated along with a
> > >> tool which would render those xlations into a bitmap of the
target
> > screen/popup/window
> > >> in a pre-determined font.
> >
> > > Its the... tool which would... that is missing here.  Since the
> > > translations are platform agnostic you would need a tool for each
> > > toolkit that could render the results.
> >
> > This is the way I also see it.
> >
> > The current workflow in Pootle is:
> >
> > Vendor format -> (POT) -> PO.
> >
> > In other to show how the translation looks in the app, you'd need to
do
> > the following for each segment:
> >
> > PO -> (pomerge) -> Vendor format -> vendor format resource viewer
> >
> > In other words, it won't be impossible, but it would have to work on
a
> > vendor format specific basis and you'd need a resource viewer that
can
> > already convert the vendor format string into a screenshot of it.
> >
> > >> - more about abbreviation support: the abbreviations would be
> > >> associated with a particular word or phrase.
> >
> > > Well the terminology lists that we currently support can easily be
> used
> > > for that.
> >
> > What would be nice would be some way to add to the glossaries from
> > within Pootle, so that users who create abbreviations can add them
to
> > the glossary.
> >
> > There is currently no pofilter that checks to see if a word occurs
in
> > the source, that a certain other word must occur in the target.
Such a
> > check would be great (also for checking correct usage of
terminology).
> >
> > >> - String usage:  it would be useful to have a way to keep track
> > >> of where a particular word or phrase was used.
> >
> > > We don't do that now.
> >
> > True, but can't you use pogrep to get a list of strings where the
term
> > occurs, and check the comments of those strings to get some sort of
clue
> > about where they were used?
> >
> > Samuel
> >
> >
------------------------------------------------------------------------
> -
> > This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems?  Stop.
> > Now Search log events and configuration files using AJAX and a
browser.
> > Download your FREE copy of Splunk now >> http://get.splunk.com/
> > _______________________________________________
> > Translate-pootle mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/translate-pootle

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Translate-pootle mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/translate-pootle

Reply via email to