Alan Burlison wrote:
Fuyuki Hasegawa - Sun Microsystems wrote:
Well, CTI introduces further issue...
CTI will split a single msg into plural segments by sentence delimiter
such as '.', '?'. For example, the msg below
OK=I was born at my mother's house. The mother's house was in {0}.
will be split into the following two segments.
I was born at my mother's house.
The mother's house was in {0}.
In this case, the apostrophe in the former segment also needs to
be duplicated. However, this can not be detected without referring
actual message src file, or CTI needs to be able to show msg key
information or stop splitting into plural segments for .properties.
Splitting the sentences probably makes sense for documentation, but for
text displayed in a user interface of some sort, it seems like it might
be a mistake. Even if a message is split into multiple sentences, the
sentences will most likely rely on each other for context.
Splitting the sentences is for better 100% match TM leverage.
Changing .properties filter affects all of the existing TM data for
all projects. It requires lots of manual adjustment effort...
Anyway we can live with post-processing way before integrating to
the product. That is, creating a script that if there are single
apostrophes with placefolder in a msg, duplicate the apostrophes
while we also need to do the same change against TM data for
future leverage.
It would be great if we could implement this check mechanism
directly in CTI, that is, whenever double apostrophes is required,
CTI warns it during translation. Then, we don't need to have the
post-processing against both translated src files and TM data. :-)
The other thing that might help was if the tool displayed the message
keys as well as the text, partly because that could provide context, but
also because it makes it possible to see where they are used in the source.
I talked with a person who is familiar with CTI development.
The option displaying msg key has been included in RFE list.
It may also be good to add the function to display original src file.
For example, all our validation messages require quote-escaping, and the
keys all begin with 'validation', so knowing the message key helps.
However, having noted those two niggles aside, I've been very impressed
by the translation work that's been done by the I18N community for Auth,
which has far exceeded even my most optimistic estimates - even if being
given Arabic did mean that we had to go figure out the whole RTL thing
;-) I hope we've done a reasonable job, figuring out how to get the
menus to switch sides and how to get visual elements such as icons to
reorder correctly was an interesting challenge :-)
Once again, a big 'thanks' to the community!
I also would like to express my thanks to the community contributors!!
Thanks,
Fuyuki
_______________________________________________
website-discuss mailing list
[email protected]
