> Insert and update are not db dependend that's correct but
> UTF-8 encoded
> data is the same like binary encoded data (e.g. Chinese characters on
> the commandline).
And that you cant export to a .sql file?
Cant imagine that.
Hmm i think i have to do some tests :)
Regards til
smime.p7s
D
Obes, Til wrote:
Whats wrong with a .sql file?
This is database dependend and we cannot edit it with standard tools.
SQL files and UTF8 is a story for itself too. If we have
clean PO files
then we can still use standard tools.
Insert or update statements are common sql afaik.
There is nothing db
> > Whats wrong with a .sql file?
>
> This is database dependend and we cannot edit it with standard tools.
> SQL files and UTF8 is a story for itself too. If we have
> clean PO files
> then we can still use standard tools.
Insert or update statements are common sql afaik.
There is nothing db
hi Til,
Whats wrong with a .sql file?
This is database dependend and we cannot edit it with standard tools.
SQL files and UTF8 is a story for itself too. If we have clean PO files
then we can still use standard tools.
Michael
--
___
Mic
Hi Martin, Hi Chris,
first I don't like to reduce the features of the web interface. I only
think about the minimal first porting effort.
Martin Bartosch wrote:
in my opionion it would be best to start with a command line client.
Initialization is (IMO) a task that can easily be performed on the
> Yes, this is the reason for the scripts. If we have a central server
> translation.openca.info then we must export the translations from the
> server into the releases and from the releases into the local OpenCA
> databases. This means that we need two scripts
>
> 1. to export an OpenCA lang
Hi Til,
Obes, Til wrote:
Hmm either i dont understand you or you dont understood the translation
thing.
The complete translation will be handled with the database and there
are no more mo/po files in openca then.
You maybe can create scripts for the one time import of mo/po into the db.
But then no
Hi Michael,
> I start porting the commands to the new OpenCA API. Before I port the
> functions for the initialization of a CA to the new API does it make
> sense to put the init stuff into the web interface? Does it be perhaps
> better to initialize the CA via the commandline (only with OpenCA an
Michael,
> I start porting the commands to the new OpenCA API. Before I port the
> functions for the initialization of a CA to the new API does it make
> sense to put the init stuff into the web interface? Does it be perhaps
> better to initialize the CA via the commandline (only with OpenCA and a
Hi all,
I start porting the commands to the new OpenCA API. Before I port the
functions for the initialization of a CA to the new API does it make
sense to put the init stuff into the web interface? Does it be perhaps
better to initialize the CA via the commandline (only with OpenCA and a
runni
> No, the scripts are for the new mechanism. If we want to rollout the
> translations then we must do this with files. PO files are an
> existing
> standard. The PO files would only include the new keys and
> the relating
> english or whatever translation.
Hmm either i dont understand you o
Obes, Til wrote:
It seems that mysql reached stable with the version 4.1
So now there is full support for utf8.
So whats now with moving the translations into database?
We can do it for CVS HEAD only but therefore we need two things:
1. a database scheme (which you created already)
2. two scripts f
12 matches
Mail list logo
