[Semi-OT] A design question

[Ricardo Palomares Martinez]

Hi,

Please, don't infer anything about MT possible new features from this
question, but I really wanted to know your opinions. :-)

Let's suppose a L10n tool (like MT, for instance) were to hold a list
of en-US strings and their existing translations, sorted by
occurrences, to provide suggestions on recurred en-US strings. It
could be that the list were bound to each and every product, or that
the list were global to the program execution. So, if you have a
Glossary.zip with two products, for instance Firefox and SeaMonkey:

1) in the first case (a separate list for each product) the same en-US
string present in both products wouldn't be provide translation
suggestions (which could be good if you want to restrict terminology
to each product).

2) in the second case (the list being shared for every product in the
Glossary.zip) you would get Firefox translations as suggestions for
SeaMonkey and viceversa, provided the en-US string is the same in both
products.

The second case seems also to make easier to export those lists to
files (maybe even TMX files) and share them across multiple L10n tool
installations.

Again, please don't assume I'm working in this for MT. If things
change, you will the first to know about it (after me). ;-) Also, I'd
be glad to know if you find this as something useful or not.

TIA

--
If it's true that we are here to help others,
then what exactly are the OTHERS here for?

[Robert Kaiser]

Ricardo Palomares Martinez schrieb:

> 1) in the first case (a separate list for each product) the same en-US
> string present in both products wouldn't be provide translation
> suggestions (which could be good if you want to restrict terminology
> to each product).
>
> 2) in the second case (the list being shared for every product in the
> Glossary.zip) you would get Firefox translations as suggestions for
> SeaMonkey and viceversa, provided the en-US string is the same in both
> products.

I'd love to be able to change the strings differently for every product
but be able to easily "import" all translations for strings that apprear
elsewhere to the product I'm currently working on. MT's "Auto-Translate"
feature is working quite well for that IMHO and I'd hope to have
something like that (completed by the "inconsistent strings" check) in
every L10n tool, as it's become a quite important way of working with
the tool for me.

Robert Kaiser

[Ricardo Palomares Martinez]

Robert Kaiser escribió:

> I'd love to be able to change the strings differently for every product

Of course, the list would only provide suggestions, not mandatory choices.

> but be able to easily "import" all translations for strings that apprear
> elsewhere to the product I'm currently working on. MT's "Auto-Translate"
> feature is working quite well for that IMHO

The issue with MT autotranslate feature is (AFAIK) that if a en-US
string is translated in several different ways, it will fill empty
translations with one of the translations, disregarding the others. It
won't care either about the occurences of the chosen translation.
Finally, it also includes accesskeys and commandkeys.

> and I'd hope to have
> something like that (completed by the "inconsistent strings" check) in
> every L10n tool, as it's become a quite important way of working with
> the tool for me.

You have a somewhat special Glossary.zip, because you have in it all
products you translate, that happen to be different versions of the
same products (like SeaMonkey-branch and SeaMonkey-trunk, for
instance). It is nearly as having two copies of the same string set,
so when a string is removed and later re-added in just one of the
products, chances are that the other one still has it, making a lot
easier to get matches. OTOH, it raises the memory consumption, which
some users may consider too hungry for their hardware.

So, I'm playing with this approach to see if it works nicely. It won't
be part of MT unless the benefits outweight the annoyances.

Thank you for your answer.

[Ricardo Palomares Martinez]

Ricardo Palomares Martinez escribió:

> Let's suppose a L10n tool (like MT, for instance) were to hold a list
> of en-US strings and their existing translations, sorted by

> occurrences, to provide suggestions on recurred en-US strings. (...)

Forget about it, at least in the close future. I don't like the way I
was messing the code, so I will rethink about it and go back in the
meanwhile to my final year project, that should make things easier by
having a real database underneath.

Sorry for the semi-OT.