TMXEditor icon indicating copy to clipboard operation
TMXEditor copied to clipboard

`tuv/@changedate` is not modified after an edit

Open bansp opened this issue 11 months ago • 5 comments

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.)

bansp avatar Mar 14 '24 22:03 bansp

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.

rmraya avatar Mar 14 '24 22:03 rmraya

Such a feature would be very useful, especially for group work, I think.

bansp avatar Mar 14 '24 22:03 bansp

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.)

bansp avatar Mar 19 '24 13:03 bansp

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).

rmraya avatar Mar 19 '24 13:03 rmraya

Thanks, great to know. I'm looking forward to trying out 3.1 :-)

bansp avatar Mar 22 '24 15:03 bansp

This is now an optional feature in 3.3.0

rmraya avatar Aug 12 '24 16:08 rmraya

Thank you! :-)

bansp avatar Oct 05 '24 21:10 bansp