MT 5.1 status
Ricardo Palomares Martinez
As I've just sent two messages regarding forthcoming MT 5.1, and
before anybody asks when will it be available, I tell you how things
are going. :-)
I'm behind schedule, really. I wanted to have it ready by now, but you
know how difficult real life can be...
This is what I've accomplished by now:
* Field "Comment" added to persistance (i.e.: saved in Glossary.zip)
* Enhanced accesskeys and commandkeys vs. label & buttons detection
* Original file license (delimited with ***** BEGIN LICENSE BLOCK ***
... ***** END LICENSE BLOCK *****) now is preserved; it is possible
also include the localizer as contributor (new preference added at
File -> Setup -> License)
* Edit Image dialog now has an additional button to switch between
vertical and horizontal split. A bit rough (usually a window resize
is needed to make everything fit gently), but it works.
* CVS Import directory now correctly removes obsolete files and
entities, so there is no further needed to create a new product,
import, migrate and delete the old one.
* Multiple directory levels are correctly treated now.
This is what's left:
* Review Fuzzy management.
* Add "Clear ALL Fuzzy flags" option.
* Add "Relink labels and keys" option.
* Fix a problem with the "Show in chrome" button.
* A bit more testing with CVS mode, and a lot more with JAR mode.
I'm afraid I'm going to leave out one of the RFEs, Search & Replace.
It all depends of how I advance with the above pending tasks, but I
doubt I can make it before this weekend, and I can't afford to spend
more time on this before going with my new program.
So, I expect to have MT 5.1 working internally for my Fx, Tk and Tb
translations by next week. I'll play with SM 1.1 nightlies too and, if
I don't see anything weird in a week or so, it will go public.
Ricardo.
--
If it's true that we are here to help others,
then what exactly are the OTHERS here for?
Robert Kaiser
> * CVS Import directory now correctly removes obsolete files and
> entities, so there is no further needed to create a new product,
> import, migrate and delete the old one.
Does this mean when e.g. the change is that a file with the same keys
was moved to a different place or just the key was renamed, I can't even
use AutoTranslate to get get the old version of the string filled in, as
the old version is gone already when I have imported the new one?
(I know this is a tricky example, but if it works, it can save lots of
trouble...)
Robert Kaiser
Ricardo Palomares Martinez
> Ricardo Palomares Martinez schrieb:
>> * CVS Import directory now correctly removes obsolete files and
>> entities, so there is no further needed to create a new product,
>> import, migrate and delete the old one.
>
> Does this mean when e.g. the change is that a file with the same keys
> was moved to a different place or just the key was renamed, I can't even
> use AutoTranslate to get get the old version of the string filled in, as
> the old version is gone already when I have imported the new one?
Yes, I'm afraid you won't be able to use Auto-translate in that way.
For the case of files being moved in the tree, you could still import
the files and the result would be very similar.
The key renaming is an special case, as you know: it's done so
compare-locales.pl can work, but MT doesn't need it at all, and it's
actually an annoyance. Anyway, when a key renaming happens, it's
because the original text has changed in a semantic way, so invoking
Auto-translate shouldn't be of much help anyway. Am I missing something?
Anyway, I've been reviewing Auto-translate feature and I have sadly
discovered that it doesn't try to auto-translate only if all the keys
with the same original have just one translation, so it's a bit
dangerous. For example:
- key1.label = "Browse"
- key1.l10n = "Examinar"
- key2.label = "Browse"
- key2.l10n = "Navegar"
- key3.label = "Browse"
- key3.l10n = (null)
MT Auto-translate will auto-translate key3 (it's not clear whether it
will choose "Navegar" or "Examinar"), but I'd rather go with it
leaving the translation empty. Changing the behaviour to do so will
incurr in big timing penalty, so I won't touch it.
Once I can trust in Fuzzy flag being set and unset in a reliable way,
the Auto-translate behaviour could be a minor concern, but I wouldn't
blindly use it right now.
>
> (I know this is a tricky example, but if it works, it can save lots of
> trouble...)
OTOH, the current behaviour makes us to repeat an annoying process
every time a key or file is removed from the CVS directory layout,
since MT holds obsolete keys and files in its glossary, and you have
to create a new product, import CVS directory on it, migrate the old
product to the new one (this step only migrates existing files and
keys in the new product, thus "cleaning" the translation) and remove
the old product.
Let me know if there are any chance of finding easy solutions in MT
coding to your problems.
Robert Kaiser
> The key renaming is an special case, as you know: it's done so
> compare-locales.pl can work, but MT doesn't need it at all, and it's
> actually an annoyance. Anyway, when a key renaming happens, it's
> because the original text has changed in a semantic way, so invoking
> Auto-translate shouldn't be of much help anyway. Am I missing something?
There are cases why renaming happens because there was a typo in the key
name, or, as we had with some help-related changes to pref panels,
because the key might conflict with a different key in a new use of the
DTD file.
Additionally, there's that case of moving files that I mentioned...
In cases where both key name and string value change (which is what you
are talking about), AutoTranslate doesn't work anyways usually...
> OTOH, the current behaviour makes us to repeat an annoying process
> every time a key or file is removed from the CVS directory layout,
> since MT holds obsolete keys and files in its glossary, and you have
> to create a new product, import CVS directory on it, migrate the old
> product to the new one (this step only migrates existing files and
> keys in the new product, thus "cleaning" the translation) and remove
> the old product.
I've never done that yet - I just don't care about a few old files/keys
(no ideal solution as well, I know)... ;-)
> Let me know if there are any chance of finding easy solutions in MT
> coding to your problems.
We could probably mark keys/files as "outdated" in memory internally
while MT is running and just not save them to the glossary or exporting
them when they are marked that way. With this, they would still exist
for c&p or AutoTranslate as long as MT is running and only be gone when
closing the MT instance.
Robert Kaiser
Ricardo Palomares Martinez
> Ricardo Palomares Martinez schrieb:
>> The key renaming is an special case, as you know: it's done so
>> compare-locales.pl can work, but MT doesn't need it at all, and it's
>> actually an annoyance. Anyway, when a key renaming happens, it's
>> because the original text has changed in a semantic way, so invoking
>> Auto-translate shouldn't be of much help anyway. Am I missing something?
>
> There are cases why renaming happens because there was a typo in the key
> name,
This is a developer error, then. Fixing typos is exactly the only case
in which not renaming the key is allowed, because it is supposed that
localizers would have not reproduced the typo in the translation.
>> Let me know if there are any chance of finding easy solutions in MT
>> coding to your problems.
>
> We could probably mark keys/files as "outdated" in memory internally
> while MT is running and just not save them to the glossary or exporting
> them when they are marked that way. With this, they would still exist
> for c&p or AutoTranslate as long as MT is running and only be gone when
> closing the MT instance.
Detecting and excluding those keys when saving and exporting seems
easy, but I have strong doubts about being able to prevent them from
showing up in chrome view and maybe other table views.
Let me ask you... This current behaviour is indeed an error in MT CVS
import directory; it is not present in traditional JAR mode so, how
did you manage when only JAR mode existed? :-)
Robert Kaiser
> Robert Kaiser escribió:
>> Ricardo Palomares Martinez schrieb:
>>> The key renaming is an special case, as you know: it's done so
>>> compare-locales.pl can work, but MT doesn't need it at all, and it's
>>> actually an annoyance. Anyway, when a key renaming happens, it's
>>> because the original text has changed in a semantic way, so invoking
>>> Auto-translate shouldn't be of much help anyway. Am I missing something?
>> There are cases why renaming happens because there was a typo in the key
>> name,
>
> This is a developer error, then. Fixing typos is exactly the only case
> in which not renaming the key is allowed, because it is supposed that
> localizers would have not reproduced the typo in the translation.
I actually meant fixing a typo in the *key name*, which means that the
key is renamed actually...
And there are cases where changing the string without renaming the key
is completely OK, i.e. when the changes are not semantic, e.g. when just
expressing the same sense of a setting with better words.
Exactly the policy of renaming the keys is why I think that having the
old string still around is important though. For example, we tend to
have cases again and again where long descriptions of ChatZilla commands
are just being extended, or the meaning of one part is reversed. Losing
the old string means you have to rewrite the whole 6-line description,
when you could just copy from the old one and replace the part that
actually changed.
>>> Let me know if there are any chance of finding easy solutions in MT
>>> coding to your problems.
>> We could probably mark keys/files as "outdated" in memory internally
>> while MT is running and just not save them to the glossary or exporting
>> them when they are marked that way. With this, they would still exist
>> for c&p or AutoTranslate as long as MT is running and only be gone when
>> closing the MT instance.
>
> Detecting and excluding those keys when saving and exporting seems
> easy, but I have strong doubts about being able to prevent them from
> showing up in chrome view and maybe other table views.
They could probably be displayed and be grayed out or so...
> Let me ask you... This current behaviour is indeed an error in MT CVS
> import directory; it is not present in traditional JAR mode so, how
> did you manage when only JAR mode existed? :-)
I'm only using JAR mode (I'm not even sure how I can get into CVS mode
at all), and it seems to work for me (or, actually, the bug seems to be
present - I still have files listed which have been deleted from the
source)...
Robert Kaiser
Ricardo Palomares Martinez
> Ricardo Palomares Martinez schrieb:
>> import directory; it is not present in traditional JAR mode so, how
>> did you manage when only JAR mode existed? :-)
>
> I'm only using JAR mode (I'm not even sure how I can get into CVS mode
> at all),
Well, I use the term "JAR mode" to refer to traditional MT product
definitions (Platform neutral JAR, platform dependent JARs and Region
JAR) together with "File -> Update Product".
I use the term "CVS mode" to refer to a MT product definition with no
JARs, using "Edit -> CVS Import Directory", "Edit -> CVS Import
Translation" and "Export -> CVS Translation" options. "Edit -> CVS
Import Directory" does roughly the same that "File -> Update Product"
but, instead reading from several JARs, reads from a base directory
which is supposed to have been checked out from a CVS repository
("CVS" managment directories are explicitily ignored). MT does not
know actually anything about dealing with a CVS repository other than
ignoring "CVS" named directories.
> and it seems to work for me (or, actually, the bug seems to be
> present - I still have files listed which have been deleted from the
> source)...
Weird... Do you mean that, after running "File -> Update Product", you
still can auto-translate using strings that have been removed from the
new JARs?
All I can say is that, now, "Edit -> CVS Import Directory" behaves in
the same way that "File -> Update Product" when it comes to updating
the original strings. I haven't touched Update Product code, so it
should work the way you want.
If you want, you could do a test with MT 5.1 once I publish it and see
if it works the way you're used to, and if things aren't so good, we
can work out a solution (the biggest change in MT 5.1 is geared
towards CVS mode, so you won't miss too much *the big difference*
between 5.0x and 5.1). Beware, however, that MT 5.1 glossary file
format _will_ change, so you will need to keep a current back-up.
Robert Kaiser
> Weird... Do you mean that, after running "File -> Update Product", you
> still can auto-translate using strings that have been removed from the
> new JARs?
Yes.
> If you want, you could do a test with MT 5.1 once I publish it and see
> if it works the way you're used to, and if things aren't so good, we
> can work out a solution (the biggest change in MT 5.1 is geared
> towards CVS mode, so you won't miss too much *the big difference*
> between 5.0x and 5.1).
I will. But I'm also looking at slowly converting to "CVS mode" for my
trunk stuff - though this is also in an experimental stage (SeaMonkey
source L10n stuff), so it fits with experimenting with new MT stuff :)
Robert Kaiser