MHonArc v2.5.0b2 -->
xliff message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: AW: [xliff] Java profile feedback
Dear Tony:
I agree that replaceables are an inportant issues, but my concern is that
the placeables are just half of the story.
I assume that the idea of marking the replaceables is to make life for
translators easier. Replacebles in Java can sometimes be hard to identify
and can get corrupted much easier than in other file format. Also a nice
XLIFF editor could allow to drag and drop replacebles nicely.
What is missing: Replaceables also introduce escape schemes so that
characters used to mark-up the replaceables still can be used in the text.
I'm better here in C/C++, see the following example:
"Customer base of Smith & Johnson has been increased by %d%% in year %d"
'%%' is used to escape to a single '%' while the other occurences are used
to indicate replaceables. If this text will be used in certain situation
like in a control of a form it can be possible that it would have to be
written as:
"Customer base of Smith && Johnson has been increased by %d%% in year %d"
In this case the '&&' is escaped to '&' because '&' is used to mark the
access key in forms/dialogs.
When we mark the replacables we should also address the escaping mechanism
used in the programming languages. The translator does not need to
understand the escaping schemes specific for a certain programming language
any more. And the text could be stored in TMs and used by tools in the
process also without having to understand the scaping schemes.
This would then also involve looking at the way in rc-files shortcuts are
represented and how to make them for proper processing. The current profile
is mapping them to XLIFF as they are like (&Open\tCtrl+O").
We are highly interestd in a scheme that allows unified processing of these
kind of strings in the localization process, across tools and a way to store
this data in TMs and Termbases so that they can be retrieved in a useful way
both for document translation and software localiztion.
I have to admit that I don't have a solution in place right now and see four
options:
1. Skip tagging of replaceables in the Java profile so that all software
strings are unified "naked". This is consistent but may be puristic.
2. Keep tagging in Java but don't introduce it to the other profiles. This
is what we have and could support and relax the more difficult situation for
Java. But it is not consistent.
3. Introduce the same mechanism used in Java for the other profiles .NET and
rc. A consistent solution but not the complete solution for best
resuablility and interoperability.
4. Working on the complete soultion for all software file fomats.
I don't have the time to come up with a solution for 4. Personally I don't
perfer 3. because I would like to see a consistent and complete solution.
This is the reason why I would like to opt for the first or second option
and work on a complete solution for an update of XLIFF standard/profiles.
Best regards from Bonn,
Florian
-----Ursprungliche Nachricht-----
Von: Tony Jewtushenko [mailto:tony.jewtushenko@productinnovator.com]
Gesendet: Mittwoch, 21. September 2005 20:21
An: florian@passolo.com; xliff@lists.oasis-open.org
Betreff: RE: [xliff] Java profile feedback
Hi Florian:
Replaceables are a pretty important issue for Java Resource Bundles and I
think must remain. So the question then is do we include the recommendation
in the other profiles... or do we just leave them all as is?
How much work would be required to include this in the .NET & RCDATA
representation guides? The concept is the same so what more work would
there be other than cut/paste, and adding a couple tags to the examples?
The examples don't have to include very complex / multiple replaceables -
just a basic one would do and I see the .NET profile has a replaceable in
its sample code already. So this should be pretty simple to normalize
across all profiles - or am I missing something?
Regards,
Tony