Well,
it would obviously also be possible to share an executable file or a
patch against one within your team.
also possible would be to simply have a Google-Chrome specific
localization thing- easy,XML and fast. The concept would be a fixed-
length array of strings in a class. THe class also contains methods to
load strings from a file( maybe even write them so someone can make an
editor in-chrome) and an overload of the [] operator that allows you
to access a string by numerical index(which is defined as a compiler
macro constant) - extremely fast as for release builds you can, if you
use careful unit-testing, omit index checks and get the same
performance as any array ( as it does the same if the function is
inlined). This would allow EXTREMELY fast string access from chrome
with a minimum amount of code.
I am obviously not very XML skilled, but I can make little code(from
the top of my head, untested, and according to my own code
conventions),which uses an easier format that can be easily replaced
by XML:
The format has the advantages of being very fast and easy to
understand( easier than XML, believe me) and it should be able to
support UNICODE if the library is built against unicode ( use
wchar_t / similar instead of char then and correspondsing standard
library calls)
///ChromiumLocale.h (c) 2008 Julian Bangert . BSD Licence as specified
in LICENCE
#pragma once
#ifndef CHROMIUMLOCALE_H
#define CHROMIUMLOCALE_H
// the strings all get a numeric constant,
enum Locale{
//Various string
GoogleChrome = 1, // " Google Chrome". The first string to be loaded,
IDs tart with 1
_Last // NON-Standard to use the constant Locale::_Last, but supported
by every compiler I know( IDK who wants to compile Chromium on
Metrowerks on similar exotics)
};
#endif
///StringManager.h (c) 2008 Julian Bangert . BSD Licence as specified
in LICENCE
#ifndef STRINGMANAGER_H
#define STRINGMANAGER_H
#include <cassert>
#include "ChromiumLocale.h"
//you obviously got to use a better error handler
public class StringManager
{
private:
StringManager *instance;
char **strings; // replace by std::string if needed. NOT
A multidimenisional array
StringManager()
{
strings = NULL;
numstrings = 0;
}
StringManager(StringManager& ref) { throw "Cannot copy
Singleton StringManager" };
public:
inline char* GetString(unsigned int index)
{ ASSERT(index < Locale::_Last); return strings[index]; }
static StringManager *GetInstance() { if(!instance)
{ instance = new StringManager(); } return instance; }
bool LoadTable(const char* file);
char* operator[](unsigned int index){return GetString(index);}
}
#endif
///StringManager.cpp (c) 2008 Julian Bangert . BSD Licence as
specified in LICENCE
#include <cstdlib>
#include <cstdio>
#include "StringManager.h"
//Reads in files in the format (string number):(text)
bool StringManager::LoadTable(const char *file);
{
size_t len,filesize; //Length of current line
char *buf,*line,*end; //Buffer the file here for increased
performance as we make many nano-operations(reads, etc) and it is
faster to cache
FILE *file = fopen(file,"r"); //file handle
unsigned int numstrings = 0; // number of strings
unsigned int currstr = 0;
if(!file)
return false;//throw "Could not open localization file";
if(!fseek(file,0,SEEK_END));//get size
return false; //throw "Could not Seek"
filesize = ftell(file); // Get Filesize
buf = (char *)malloc(filesize + 1); //allocate file buffer
strings = (char **)malloc(Locale::_Last * sizeof(char *)); //
Allocate table part 1
if(!buf || !strings)
return false;// Out of memory
fread(buffer,4,filesize/4 + (filesize % 4),file); // this is usually
faster on 32bit and 64 bit architectures as they are allowed to read a
full cycle(or half cycle) from the disk via their interface instead of
only 1 of 4 bytes ( at least from their cache).
buf [filesize] = '\0'; // to avoi buffer overflow
end = buf + filesize;
// If someone would please benchmark fread(buffer,1,filesize,file); I
would be most grateful
// good implementations of the C STL would implement this by reading
full cycles anyway,but this can break standard compatibility when not
done carefully- Julian Bangert
// mmap might be a non-portable alternative, but it usually suffers
some performance constraints for smaller files
register char *ptr = buf; // start out reading file, the most used
variable in here, best to put it in DX as DS:DX would be great here(if
anyone wishes to make this assembler as well)
while(ptr < end)
{
if(!isdigit(*ptr)) // Comment lines starting with a non-number
are
ignored
continue; // comment lines
currstr = atoi(ptr);
if(currstr < 0 || currstr > Locale::_Last)
continue;
ptr = strchr(buf,':'); // it is intended that we can skip
newlines,
comments , etc
line = ptr; // store that for easy retrieval later
ptr = strcspn(buf,"\n");// already returns string length when
there
is no newline
*ptr = '\0';
ptr++; // Increment already, this will save one ddition below
when
allocating NULL character
strings[currstr] = malloc(ptr-line); //strlen is already
calculated
+ NULL character
if(!strings[currstr])
return false; //Out of memory
strcpy(strings[currstr],line);
}
return true;
}
// YES: I am a geek, YES: It took me 30 mins to write that( I didn't
want to present something hush-hush to the public) NO I did not test
it. NO I do not have much time
// YES I read Don Knuths books for recreation YES I understood them.
NO I do not have one of his cheques and NO I won't summarize it for
Mr. William Gates (whoever he may be) unless he pays me 7 or more
figures for it ;) ( I accept cheque , wire , cash,please no paypal)
On 21 Sep., 21:37, "Simon B." <[EMAIL PROTECTED]> wrote:
> For translators it can be very useful to have the translations file as
> a separate data file. With using gettext, I could fix up the Swedish
> translation and test it out before propagating my changes upstream. As
> it is now, I have prepared some half-hearted attempt and waiting for
> The current approach with a DLL-file still allows for switching and
> sharing withing a translator group, but those xtb files are
> mysterious. Searching didn't give any good results! xtb might mean
> "xml translationbundle" or something?
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Chromium-dev" group.
To post to this group, send email to chromium-dev@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/chromium-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
