scrollkeeper-devel

[Scrollkeeper-devel] Better internationalization support

[Laszlo K. <las...@Su...>]

Hi,

I would like to implement this, but I think we still have some issues to
clarify. I think there are two problems here:

1. Using xml-i18n-tools to translate the category trees.
2. Being able to identify a doc and all of its translations easily.

1. depends on xml-i18n-tools that (I think) creates a message file from
the XML file and merges back all the translations into the original
file. This will be changed in the near future to create separate XML
files for each translation. It seems we will not use it until this is
not done so translation will be done by hand until then.

2. This is the long discussed document ID and this is what I would like
to address. We want an ID that is the same a document and all of its
translations and it allows to find the English doc if the translated one
is not there or fall back to other translations of the doc (like first
to German then to English if the French is not there. I think the main
problem is not how to implement the fallback mechanism, but how to
assign these IDs, how to make the docwriters, translators to request the
ID and how to send it to them. It should be very easy for anybody to
generate an ID like this. Then I think it should be down to the
docwriters, translators to make sure to use the same ID for a doc and
all of its translations. Uidgen was mentioned to be used to generate the
IDs. As this is not available on every platform a web based request
mechanism with a Linux server could be a good approach (like ask the
Linux server for a number). This should probably all be hidden inside a
Scrollkeeper script or binary that just retrieves an ID whenever run. 

Any thoughts?

Laszlo

[Scrollkeeper-devel] Better internationalization support

[Bob S. <bo...@sc...>]

> 2. This is the long discussed document ID and this is what I would like
> to address. We want an ID that is the same a document and all of its
> translations and it allows to find the English doc if the translated one
> is not there or fall back to other translations of the doc (like first
> to German then to English if the French is not there. I think the main
> problem is not how to implement the fallback mechanism, but how to
> assign these IDs, how to make the docwriters, translators to request the
> ID and how to send it to them. It should be very easy for anybody to
> generate an ID like this. Then I think it should be down to the
> docwriters, translators to make sure to use the same ID for a doc and
> all of its translations. Uidgen was mentioned to be used to generate the
> IDs. As this is not available on every platform a web based request
> mechanism with a Linux server could be a good approach (like ask the
> Linux server for a number). This should probably all be hidden inside a
> Scrollkeeper script or binary that just retrieves an ID whenever run. 

> Any thoughts?

> Laszlo

In December, I posted an alternative approach
using URNs.  I didn't get any response at the time,
perhaps because my mail was so long.  8^)
A URN is human comprehensible, can be generated
locally without tools, and, by following a simple
namespace convention, can be globally unique.

The syntax of a URN is:

   urn:namespaceID:documentID

The "urn:" part is fixed, and the other two parts
are assigned by the document originator.
Each organization can define its own namespaceID,
and then they just need to keep their own documentIDs
unique within that namespace.

The key to global uniqueness is ensuring that
each namespaceID is unique.  This can generally
be achieved today by following the convention
of using their own IP name, such as apache.org
or ldp.org.  If an individual lacks an IP name, they can apply
to OMF to register their documents under the omf.org
namespace.

So the LDP could use URNs such as:

urn:ldp.org:SysAdminG
urn:ldp.org:ls.man.1
etc.

I've attached my original mail which provides further
background information and references on URNs.

bobs
Bob Stayton                                 400 Encinal Street
Publications Architect                      Santa Cruz, CA  95060
Technical Publications                      voice: (831) 427-7796
The Santa Cruz Operation, Inc.              fax:   (831) 429-1887
                                            email: bo...@sc...

Re: [Scrollkeeper-devel] Better internationalization support

[Laszlo K. <las...@Su...>]

> In December, I posted an alternative approach
> using URNs.  I didn't get any response at the time,
> perhaps because my mail was so long.  8^)
> A URN is human comprehensible, can be generated
> locally without tools, and, by following a simple
> namespace convention, can be globally unique.
> 
> The syntax of a URN is:
> 
>    urn:namespaceID:documentID
> 
> The "urn:" part is fixed, and the other two parts
> are assigned by the document originator.
> Each organization can define its own namespaceID,
> and then they just need to keep their own documentIDs
> unique within that namespace.
> 
> The key to global uniqueness is ensuring that
> each namespaceID is unique.  This can generally
> be achieved today by following the convention
> of using their own IP name, such as apache.org
> or ldp.org.  If an individual lacks an IP name, they can apply
> to OMF to register their documents under the omf.org
> namespace.
> 
> So the LDP could use URNs such as:
> 
> urn:ldp.org:SysAdminG
> urn:ldp.org:ls.man.1
> etc.
> 
> I've attached my original mail which provides further
> background information and references on URNs.

I read that email back in December, but this explanation above seems to
clarify loads of things. I think I like this idea. At the bottom of your
previous email you suggested that omf should be the namespace for every
document handled by Scrollkeeper. I think it would be better if this
would be named after the organization or project who produces the ID.
Like urn:gnome:... or urn:kde:... . If we use omf for namespace then I
think we will need to validate the URNs used by developers of various
projects, while otherwise this would be done by them. We just need to
publish a description about how the URNs should be created.

If we do it like this then we just have to publish this recommendation
and we are done. And I can start development:-)

Note that I still see this mainly as support for identifying a doc and
all its translations uniquely. So these documents should all hold the
same id. Therefore using the <identifier> tag from OMF might not be the
best for this as the only way I can figure out that this is the ID that
is the same for the doc and all its translations is that it begins with
the word "urn". If we want to use URNs later for something else then we
would be in trouble, I think. It could be something like
urn:translation:... so we know that this URN is for translation
identification. In which case only the last part of the URN is available
to identify the doc and that might not be enough to keep the uniqueness
of the ID. 

But I really think generally this is the way to go.

Thoughts?

Laszlo