This is my entire reflection about that issue. it's very long, so, it's the
perfect reading for a rainy day;-)
I� THE PROBLEMS
The current system compares the date of the last modification of the english
files with the date of the last modification of the translated files. A
translated document is regarded as up-to-date if the date of that document is
strictly more recent than the date of the english file (if the date is the
same, the translation is considered outdated).
I see at least 3 kinds of bad behaviour with that system:
1)
a totally new version of the Y.inc file is published: 12h35, may 15
a typo bug is fixed in the french Y.inc: 15h27, may 15
What's happen? The french Y.inc is regarded as up-to-date, but, it's a
tranlation of the old version of the english Y.inc!
2)
A web developer modify an URL in the Z.inc file, he also update the italian
Z.inc file simultaneously. The two files have the same last modification's
date: the italian Z.inc is regarded as outdated!
3)
A web developer just fixed a typo bug in the english W.inc (no modification
is needed in the german W.inc): the last modification's date of the english
file is more recent than the date of the german W.inc file, so the W.inc file
is regarded as outdated!
II� IN SEARCH OF A SOLUTION
a) Two bad ideas
for the second problem (the URL modification), we can simply modify the
behaviour when the dates are the same: the translation is considered
up-to-date in that situation. It's not a good idea: if the developer modify
the URL in the english and the italian Z.inc file, but add simultaneously a
new paragraph in the english Z.inc, the italian is regarded as up-to-date
with that new system. It's also a bad behaviour.
For the third problem, we can let the translators "swindle" the CVS system
sothat it updates the translated version. Of course, it's not a good solution.
b) An almost good idea
Thanks the first problem, it's easy to think the solution is using the
version number of the english file (the version number attached by the CVS),
and the, for example, french coordinator states precisely the french Y.inc
file is a translation of the english Y.inc version 1.3 (and the last version
of the english Y.inc is 2.0), sothat the system knows the translation is not
up-to-date.
(Where? I think the version numbers of the translations can be stored in a
special file for each language, because, if I have perfectly understand the
way the php code create the html output, it must know if a translation is
up-to-date before including that translation in the html output (like the
page-titles.inc).
For the version numbers of the english file, I see two ways :
- a special file is created automatically with the CVS information
- the php code uses dynamically the CVS information)
my first idea was to use that new information in that way:
if date(english Y.inc)>date(french Y.inc) then
outdated
elsif version(english Y.inc)>version(french Y.inc) then
outdated
else
up-to-date
endif
But, that system doesn't solve the third problem. Conclusion: we can't use
the last modification's date, we must content ourselves with the version
number, so:
c)an another bad idea
instead of using the CVS number version, the web developer maintain manually
a special file for the version number of the english file, and doesn't
increment the version number when they only fix a typo bug. It's not a good
idea, because: the english developers must think to manage that file, if they
forget to increment when necessary? if they increment even if they just fixed
a typo bug? The version numbers of the english files lose their special
status, because anybody with a CVS write access can modify those version
numbers (to compare: you can't decrement the last modification's date of a
file)
d) My best solution (for the moment)
if version(french Y.inc)>version(english Y.inc) then
## such a version number is incorrect
modify the special file (***) by replacing the version number of the
translation by -1
consider the file is outdated
elsif version(french Y.inc)=version(english Y.inc then
up-to-date
else
outadated
endif
The behaviour when version(french Y.inc)>version(english Y.inc) needs an
explanation: when I want to see if a concept is realistic, I see if it is
resistant to a malicious spirit. So, with the current system, it's always
possible to force the update of a translated file, sothat it is regarded as
up-to-date, even if it is totally outdated. But, it's impossible to use a
future date : when you modify a file at 21h25, may 15, its last
modification's date can't be 20h00, july 17! We can see that behaviour like a
minimum security behaviour : that's why I reproduce that behaviour with the
version number system. Thanks that security check, that new system is no
more, no less, secured (or insecured) than the current system. So, I think
it's the good way to determine if a translation is up-to-date.
(of course, that new system can't automatically know if a translation is
up-to-date or not. For the third problem, perhaps a german translator must
update that special file himself, but it is infinitely better than
"swindling" the CVS system sothat it updates the translated version, and that
new system manage perfectly the first problem)
(***)We must answer to a technical question : wich special file must be
modified : the version copied in the web area? the version in the CVS area?
if only the modified files in CVS are copied into the web area when that area
is updated, only the version in the web area must be modified.
But, if all the www module is copied into the web area for each update, the
CVS version must be modified likewise. Why? Imagine I create an incorrect
french special file with Y.inc's version number equal to 2.0, while the
version number of the english Y.inc is 1.3. Only the web area is modified.
Later, a new version 2.0 of the english Y.inc file is published : my special
file with version(french Y.inc)=2.0 will become correct, because the correct
file in the web area is overwrite with the incorrect file from the CVS, and
the version of the english Y.inc file is now 2.0! It's not a correct
behaviour because the version 2.0 was proposed by the french special file
before that version was created.
a little improvement : if we want the security level is *exactly* the same
than the current system, the integrity check of the special file must be done
during the update of the web area (moreover, we gain time calcul because it's
not necessary to make that control again with the php code)
THAT'S ALL FOLKS :-)
Thoughts?
JSL
_______________________________________________
Web mailing list
[EMAIL PROTECTED]
http://www.uprizer.com/mailman/listinfo/web
