Hi Przemek,
Many thanks for your suggestions. I'm afraid
I'll quickly run out of my C expertise to rework
everything to another new format, but what you
say may all make sense.
As for serialize functions and hash, I'm not sure
they would be more efficient than now, especially
for loading. I have multiple language files around
700K, and they may be swapped at runtime when doing
specific stuff, like printing a document in foreign
language. Also, I very very rarely need to access
these translations explicitly (I expect the same
from other programs), so accessing them as hash is
IMO not a top necessity, but could indeed make the
solution more native and complete. I didn't do
measurements, so it may be possible we're talking
about fractions of time beyond perceptions, but
surely, gettext and load should be quick.
I have my ages old .pot processor written in
(now) Harbour, so I didn't need that part
personally, but it'd surely be useful. It can
be a bit different depending on how ppl want
to use this, for example I don't have translation
'domains' in my app (yet?), so I'm compiling
two separate .pot files into one language file
(yes, handling possible collisions is an issue).
Another useful tool (which I also have as a
very hackish and old Clipper program), is to
update an already existing .pot file from the
source, while keeping existing translations and
comments intact, backup deleted strings and
mark new ones as such. There are probably
better/standard tools for this job though.
I'm currently trying to create a higher level layer
(written in Harbour, based on my old functions
with similar purpose) to implement hb_i18n_gettext(),
but I already see that writing it in a generic
way may need too much special logic inside RTL for
my taste, so maybe it won't be committed.
I've been also thinking of using the .mo format, but
didn't see a good reason yet.
Anyhow pls feel free to modify these functions
as you think it's best.
Brgds,
Viktor
On 2008.11.01., at 16:40, Przemyslaw Czerpak wrote:
On Sat, 01 Nov 2008, Szak�ts Viktor wrote:
Hi Viktor,
; NOTE: The internal format of 'trs' (loaded translation) is also
different. For minimal memory/speed overhead, I've
choosen a one
dimensional array, as opposed to the original two
dimensional
(like the input aSortedTable array).
I suggest to use internally hash array instead of normal array.
It will be more flexible on .prg level because user can simply make:
trs[ cText ] := cTranslation
and then:
? trs[ cText ]
We should also add support to process .pot files generated by
compiler with
-j option:
proc main()
? HB_I18N_GETTEXT( "Hello World !!!" )
return
to create final version compatible with format you added.
Please also remember that you can use hb_serialize*() functions to
convert Harbour items to text and hb_deserialize for reverted
conversion.
It may simplify the code and will be easier to create helper tools
at .prg
level. It's time to make some serialize functions public. See rtl/
itemseri.c.
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
