Advantages to using xml in a small translation and localisation company

[Simon Harvey]

Whato chaps,

I work (or am hoping to work! for a company that specialises in the
following:

- Localisation of media - including software, manuals, literature and
training material.
- Creating training material themselves in many langauges built to order.

The main thing I'm thinking about for the company is maybe a sort of content
management system whereby they can provide a system that allows customers to
organise their training material and even make new material on the fly.
Thats just one area.

On the whole, I am wondering if anyone has any ideas about how xml, xsl and
all the rest of the new data technologies could be used in a company that
specialises in translation of all sorts of material but especially, training
material, marketing material and business presentations

Any help would be really really greatfully received

Thanks everyone

Simon

 

[Chris Barber]

Thats a fairly large scope!

There are two mechanisms where XML may help:

1. You have multi-language materials where the XML could contain a reference
to the 'virtual' material but the child XML would contain the real
references to the materials (one per available language). When allowing
users to choose a material, they would only be given choices where the
language exists for them or they could be given the choice to download in
any language.

<xml>
<materials>
<material title="A document">
<localised>
<materiallocalised language="French" title="Le document"
ref="get it from here url">
<materiallocalised language="German" title="Ein
document" ref="get it from here url">
</localised>
</material>
</materials>
</xml>

Please excuse my useless french and german!

2. Use XML to 'generate' the materials in HTML / PDF form in which case the
source document would contain the base representation of the document and
embedded / referenced document(s) would contain the localised strings,
images etc. An XSL stylesheet with a parameter passed in would generate the
relevant localised version.

* SOURCE XSLT *
...
<xslarameter name="language">French</xslarameter>
<xsl:variable name="localisedstrings"
select="document({$language}.xml)/root"/>
...
<!-- The title appears here selected from the referenced localised xml
file that is determined from the passed in parameter -->
<p id="title">
<xsl:value-of select="$localisedstrings/title"/>
<img src={$localisedstrings/title/@imagesrc} style="float: right"/>
</p>
...

etc.

* SAMPLE LOCALISED STRINGS XML - called French.xml *
* Others would exists as German.xml etc.
*

<root>
<title imagesrc="titleimage_french.gif">Documentation de l'internet
localise</title>
</root>

XSL-FO would obviously give you PDF capabilities - as would a component that
transfroms HTML output to PDF (such as ABCPDF3).

OK - that's pretty basic of course and I'm sure there are other systems out
there to handle this sort of thing but I hope you see what I'm trying to
demonstrate.

I have no idea how the encoding would be affected by this but I'm sure it
would be workable.

Chris.

Whato chaps,

I work (or am hoping to work! for a company that specialises in the
following:

- Localisation of media - including software, manuals, literature and
training material.
- Creating training material themselves in many langauges built to order.

The main thing I'm thinking about for the company is maybe a sort of content
management system whereby they can provide a system that allows customers to
organise their training material and even make new material on the fly.
Thats just one area.

On the whole, I am wondering if anyone has any ideas about how xml, xsl and
all the rest of the new data technologies could be used in a company that
specialises in translation of all sorts of material but especially, training
material, marketing material and business presentations

Any help would be really really greatfully received

Thanks everyone

Simon

 

[Marrow]

Hi Chris,

<xml>
<materials>
<material title="A document">
<localised>
<materiallocalised language="French" title="Le document"
ref="get it from here url">
<materiallocalised language="German" title="Ein
document" ref="get it from here url">
</localised>
</material>
</materials>
</xml>

One small point - it would be better to use the existing @xml:lang attribute
rather than re-invent your own language attributes. The @xml:lang attribute
has several advatnages, including the ability to use the lang() XPath
function.

Cheers
Marrow
http://www.marrowsoft.com - home of Xselerator (XSLT IDE and debugger)
http://www.topxml.com/Xselerator

 

[Simon Harvey]

Thanks Chris and Marrow

Well, the first example that you give, I hadnt really thought about. But
that could be a good approach so thatnks for that. You know, I would
probably try to use that in conjunction with the second approach.

The second approach is what I was thinking as well.
Two questions:

1. What is the language element for? Why was it included?
2. What I am really after is some ideas on other applications that would
make the whole xml change more worth while. Does anyone have any killer
applications that could be used in a small translation and localisation
company? Unlike the big boys, we can't affor to invest a lot of resources in
an area that won't really make much of a difference to the business. I have
come up with some advantages, such as distributing material in different
formats, but i dont know how much market there is going to be for that.
3. Another quick question. Based on your experience guys, do you think the
stylesheets should be stored on the file system or in a database? File
system sounds messy? Any thoughts?

I'm somewhat apprehensive about this are because I would be the only
developer at the company, and I am a bit wary about taking us deep into xml
because that may mean that it becomes very hard for the other staff to make
changes to documents. Making the slightest changes to a stylesheet, at the
moment, is still fairly complicated even using the tools that are available
(thanks marrow).

I think this is the underlying dilema that smaller companies are facing at
the moment. Companies in the media business could probably all benefit from
using xml and xsl technologies, but at the moment the resources required are
largely out of their reach. Most publishing companies are not specialised in
computer technologies any more than they need to be, and this is compounded
by the complexity and newness of XML technologies.

What do you think?

Oh and do you know of any companies looking for a really handsome, charming,
talented, intelligent, driven, graduate with far more experience and skills
than his peers?

Kind regards everyone

Simon

 

[Chris Barber]

Thanks Marrow.

I've looked at a few references for this but I'm not sure that it would be
fully appropriate for an entire document in multiple languages?

A possible problematic example would be a manual in French, Italian, English
and German. If the language sections were contained within the same XML
source then the source would conceivably be up to 4x larger than a single
language source.
This could present issues with speed and maintainability?
It's also feasible that a particular document might want to use a different
layout to the other documents (Chinese springs to mind). I can also see
issues where different authors are maintaining the individual languages -
source control for a single document could become very problematic.
Of course there are a multitude of issues with a multi-document system.

I wasn't making a proposal as such, just trying to put up some scenarios as
starting points.

Cheers,

Chris.

Hi Chris,

<xml>
<materials>
<material title="A document">
<localised>
<materiallocalised language="French" title="Le document"
ref="get it from here url">
<materiallocalised language="German" title="Ein
document" ref="get it from here url">
</localised>
</material>
</materials>
</xml>

One small point - it would be better to use the existing @xml:lang attribute
rather than re-invent your own language attributes. The @xml:lang attribute
has several advatnages, including the ability to use the lang() XPath
function.

Cheers
Marrow
http://www.marrowsoft.com - home of Xselerator (XSLT IDE and debugger)
http://www.topxml.com/Xselerator

 

[Marrow]

Hi Chris,

Ah, I wasn't really commenting on which approach to use - I thought you'd
covered that thoroughly. I was just commenting that, if using an approach
that invloved attributes that defined language content of a specific
node/nodes, it would be better to use @xml:lang.

As to whether to use a multiple document approach (with each translation in
a seperate document) or just a single document - it depends on the system.
But in this situation (say, for manuals) then yes, I would imagine a
multiple document approach would involve less hassles. Although there might
still be a place for an additional single XML document for semi static
stuff - for example, translations of words like 'index', 'page', 'chapter'
etc.

Cheers
Marrow

 

[Simon Harvey]

Thanks for that Chris,

Here's the important thing - most small companies don't have a dedicated IT
staff able to make constant changes to the site at short notice. The usual
model is that there is a single individual that has a number of roles, one
of them being maintaining the website. That produces a bottleneck and
eventually comapnies begin to resent making new content, which is a shame,
because content is exactly what makes a website interesting.

So, my point is, I'm going to be that person, UNLESS, there is someway to
make XSLT hidden from the content makers. I have to say that I wouldnt think
making XSLT docs is easier than say jsp or asp.net though. The difference is
though, that XSLT has a number of well known advantages. The problem is
using xslt in a way that doesnt scare non-techs

Simon

 

[Chris Barber]

XSLT can be hidden but it does mean that you have to have in place some form
of content management accessible to all. I've seen it done in a web
environment (image upload, document upload etc.) and dynamic HTML editing
using the MS html edit control.
It should be possible to have a basic XML layout for a document that defines
what the document is (eg. ID, name, description, keywords etc.) and then
allow the specific document to be edited from a series of defined templates.
Storing it all in a database then allow the site content to be dynamically
created using the defined XSLT documents combined with the XML.

Chris.

Thanks for that Chris,

Here's the important thing - most small companies don't have a dedicated IT
staff able to make constant changes to the site at short notice. The usual
model is that there is a single individual that has a number of roles, one
of them being maintaining the website. That produces a bottleneck and
eventually comapnies begin to resent making new content, which is a shame,
because content is exactly what makes a website interesting.

So, my point is, I'm going to be that person, UNLESS, there is someway to
make XSLT hidden from the content makers. I have to say that I wouldnt think
making XSLT docs is easier than say jsp or asp.net though. The difference is
though, that XSLT has a number of well known advantages. The problem is
using xslt in a way that doesnt scare non-techs

Simon

 

[Simon Harvey]

Your right there chris, and that exactly what I'm looking at actually.

A couple of questions:

How can Dynamic HTML editing be done in a browser. I actually answered
someone else's question on this very topic. He wanted the users to be able
to create their own templates in a browser. The only things I have come up
with is a technique that MS Sharepoint uses to allow the user to customise
pages, put I havent the foggiest how they do that, because I would love to
know.

Also, what is the MS HTML edit control. are we in the same ball park with
these two things.

At the moment I am using Macromedia Contribute to do this sort of stuff. Its
a god send for non tech content authors and is a great price. I'd like some
other options as well though.

Simon

 

[Chris Barber]

Found it - once I get it dragged up to the right server I'll bung it up
online for you and let you have a login (it's a database login this time),
not a NT user account.

It's pretty complex but it looks like the majority of the DHTML editor bit
is in one page and encapsulated within a JavaScript include file.

Chris.


OK - I'll have to dig in the archives but a friend of mine gave me a copy of
his site that does dynamic - to database - HTML editing in the browser using
an ActiveX control (dhtmled.ocx ?). Allows images to be uploaded and then
selected and inserted into the HTML page.

Chris.

Your right there chris, and that exactly what I'm looking at actually.

A couple of questions:

How can Dynamic HTML editing be done in a browser. I actually answered
someone else's question on this very topic. He wanted the users to be able
to create their own templates in a browser. The only things I have come up
with is a technique that MS Sharepoint uses to allow the user to customise
pages, put I havent the foggiest how they do that, because I would love to
know.

Also, what is the MS HTML edit control. are we in the same ball park with
these two things.

At the moment I am using Macromedia Contribute to do this sort of stuff. Its
a god send for non tech content authors and is a great price. I'd like some
other options as well though.

Simon

 

[Neil Smith]

OK - I'll have to dig in the archives but a friend of mine gave me a copy of
his site that does dynamic - to database - HTML editing in the browser using
an ActiveX control (dhtmled.ocx ?). Allows images to be uploaded and then
selected and inserted into the HTML page.

Not necessarily - it allows images to be placed into the layout, but
dhtmled on its own does not perform the file POST requests necesary to
send the images with the HTML file.

Also, the activeX is no longer needed on IE5 and above, you can run
the same commands it suopports directly on a DIV or IFRAME area with
the editable=true attribute.

Cheers _ Neil.

Chris.

Your right there chris, and that exactly what I'm looking at actually.

A couple of questions:

How can Dynamic HTML editing be done in a browser. I actually answered
someone else's question on this very topic. He wanted the users to be able
to create their own templates in a browser. The only things I have come up
with is a technique that MS Sharepoint uses to allow the user to customise
pages, put I havent the foggiest how they do that, because I would love to
know.

Also, what is the MS HTML edit control. are we in the same ball park with
these two things.

At the moment I am using Macromedia Contribute to do this sort of stuff. Its
a god send for non tech content authors and is a great price. I'd like some
other options as well though.

Simon

========================================================
CaptionKit http://www.captionkit.com : Production tools
for accessible subtitled internet media, transcripts
and searchable video. Supports Real Player, Quicktime
and Windows Media Player.

VideoChat with friends online, get Freshly Toasted every
day at http://www.fresh-toast.net : NetMeeting solutions
for a connected world.

 

[Simon Harvey]

Hmmm, so dhtmled.ocx is actually a well known control. Well i must have a
look at that then.
Does anyone know of anything else like that?

I would actually like to make my own activeX control but I dont know very
much about the Internet Explorer Api that I'm supposing you would have to
program in. That and the fact that I want to do it in C# but that isnt
supported in Vs2002 apparently

Simon

 

[Chris Barber]

I agree (it's difficult to get the context of a post sometimes and I
definitely get it wrong every now and then).

I'd never seen the @lang before - I'm definitely going to have a good look -
I have some stuff that I may decide to use it with.

BTW: Anything interesting developments for Xselerator on the horizon? Some
more fonts (such as Verdana) for the IDE would be handy - even on a
1600x1200 screen res I'm running out of screen space with the standard
fonts.
I'm definitely getting into this XSLT stuff in a big way and Xselerator has
helped enormously.

Cheers,

Chris.


Hi Chris,

Ah, I wasn't really commenting on which approach to use - I thought you'd
covered that thoroughly. I was just commenting that, if using an approach
that invloved attributes that defined language content of a specific
node/nodes, it would be better to use @xml:lang.

As to whether to use a multiple document approach (with each translation in
a seperate document) or just a single document - it depends on the system.
But in this situation (say, for manuals) then yes, I would imagine a
multiple document approach would involve less hassles. Although there might
still be a place for an additional single XML document for semi static
stuff - for example, translations of words like 'index', 'page', 'chapter'
etc.

Cheers
Marrow