TMXEditor
TMXEditor copied to clipboard
`tuv/@changedate` is not modified after an edit
It is great to be able to switch to this editor, thanks so much for your work, @rmraya !
I am thinking of using it as a quick-fix tool for a little multilingual corpus that I develop. It has 6 languages in parallel, but not in every tu
. I have tested it, trying to see how I can identify the modified content.
Before I made the modification, I had ingested my TMX file and immediated saved it as the same filename, in order for the editor to reshuffle the attributes and to reformat the elements -- I wanted to have a basis for file differencing.
Then I saved it again, under a modified name, and modified the content (added a translation).
The result is a file that is nearly identical to the source, but where the source has <seg/>
, the new file has
<seg>This is just an ugly test.</seg>
This is, of course, as intended.
However, the attributes of the affected tuv
got copied over to the new version of the TXM file, without modification, including one attribute that I think should get modified by the tool, namely the attribute @changedate
.
The TMX spec says:
changedate
Change date - Specifies the date of the last modification of the element.
Value description:
Date in [ISO 8601] Format. The recommended pattern to use is: YYYYMMDDThhmmssZ Where: YYYY is the year (4 digits), MM is the month (2 digits), DD is the day (2 digits), hh is the hours (2 digits), mm is the minutes (2 digits), ss is the second (2 digits), and Z indicates the time is UTC time. For example:
date="20020125T210600Z"
(source: https://www.gala-global.org/tmx-14b#changedate )
(There is one other attribute of tuv
that should get modified, namely @changeid
, which "Specifies the identifier of the user who modified the element last." But I guess that, while the former issue is arguably a bug, a modification of @changeid
might be tied to a feature request -- because the editor should probably give the user a chance to input their ID into the settings.)
The editor allows you to manually set @changedate and @changeid. It would be possible to update those attributes automatically if the user wants. This would be an optional feature.
Such a feature would be very useful, especially for group work, I think.
It seems that we're looking at a kind of grey area, where the standard backhandedly tries to impose something on the implementations, don't we? I've just quickly scanned the spec, it doesn't mention anything about the implementations in this regard, although when one thinks of use case scenarios, it is difficult to expect a translator to go low-level every time they touch a tuv/seg
, and remember about recording the date (in ISO 8601 format :-) ) and their ID.
I wonder, @rmraya -- is this a kind of feature request that is acceptable to you? And if so, is this the place where you would like it recorded?
I've been thinking that a kind of "on-change" hook could be the way to do it, with two default items:
- [x] modify the changedate (ISO 8601)
- [x] modify the changeid (either to a value set by the user as their ID or one extracted from the OS, or just "" if not set)
and, preferably, space to hook other modifications (in my case, I think I'd wish to set the element <prop type="x-status">
to "new", if I could) -- but I realise that this might be a matter for yet another feature request, as it goes above the minimal functionality.
Un-setting the two defaults would make the TMXEditor behave as it does now. Leaving them checked would make it follow the spirit of the specification. (And being able to add something else to the hook would extend the functionality further.)
Most people use TMXEditor to cleanup entries, remove duplicates or change language codes. None expect to have modified entries marked with change date of change ID.
I agree that it would be somewhat more compliant to record change information, but as users don't expect it, I would make it optional.
I will implement this feature in a future release, probably in 3.2 (version 3.1 is almost ready for release now).
Thanks, great to know. I'm looking forward to trying out 3.1 :-)
This is now an optional feature in 3.3.0
Thank you! :-)