See comments inline
-------- Original Message --------
From: Rafaella Braconi <[EMAIL PROTECTED]>
Subject: Re: [l10n-dev] new keyid builds buildable by everyone -
need help
To: [email protected]
Gregor,
when creating KeyID builds with the new keyids *on the fly*.... will we
still be able to see if a string is in the *changed* status?
No, will not be included since there is no connection to the database
anymore. Maybe there will be a simmilar mechanism in the future which
will allow to reintroduce this feature.
If that's a killer we will have to wait.
also can you may be summarize the advantages and desadvantages
(Community/Sun) of switching to new keyids?
Just a rough list:
+ Everyone can easily do KeyID builds
+ Communication about KeyIDs can be understood by Sun and Community
+ No confusion about different KeyID systems (Pavels and Suns)
+ No timeconsuming exports from database to get KeyID builds
+ Allow easy localization of automated test scripts (VCL TestTool)
- KeyIDs might get longer
- ATM no possibility to show translation status in KeyID build
- Some implementation effort needed
Thanks,
Rafaella
Gregor Hartmann wrote:
Hi all,
We are thinking about a way to allow the community to do KeyID Builds
with the same KeyIDs used by the SUN KeyID builds.
It seems to be the easiest way to generate KeyID on the fly to get rid
of the IDs stored in SUNs Database.
What I want to ask is how long these IDs can get at maximum. Would an
ID of 8-12 characters still be short enough?
So please comment on this, even if you don't care about the rest of
the mail.
Technical Stuff:
Currently it is open on how to define these IDs.
It should be possible to generate them on the fly but more important:
They should be available immediately after a new string has been
introduced to the code.
So it seems to be clear that the ID has to be generated from some
fields in the sdf file including the project, file path, Resource
Type, GID, LID and HelpID. (fields 1,2,4,5,6,7)
However the exact algorithm is not determined jet. Maybe some CRC
which can be packed to alphanumeric characters will be OK. This
however bears the risk of duplicate IDs.
Another approach would be to store the IDs somewhere in the sources
and assign them. This leaves the problem of assigning new IDs for new
strings. A simple counter in the sources will not do since there will
be collisions when introducing new IDs in several CWSes simultaneously.
If you have any suggestion or other comments or just want to state
your favorite please let me know.
Thanks
Gregor
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
