PDA

View Full Version : Additions to strings.txt



JJZolx
2005-06-23, 16:31
I noticed the recent additions to the default strings.txt and wondered what happens if someone is using a custom slimserver-strings.txt or other alternative strings file. Is there a mechanism in place to add the new stuff to custom files?

Is it planned to move these strings into the database at some point? Seems customization as well as additions could be more easily handled. Probably faster loading as well, rather than parsing a text file that will likely keep growing as new features and interface elements are added. The only real downside being that they're not as easily edited without creating some type of (web) interface to the database.

mherger
2005-06-23, 23:11
> I noticed the recent additions to the default strings.txt and wondered
> what happens if someone is using a custom slimserver-strings.txt or
> other alternative strings file. Is there a mechanism in place to add
> the new stuff to custom files?

Custom files should only contain what you want to change. Don't copy the
whole file to do your changes. You custom strings will always overwrite
the stock strings. If the latter changes, you won't notice it as you'll
still see your own version.

And if you really care about your strings, download my StringEditor plugin
to handle this easily ;-)

> Is it planned to move these strings into the database at some point?

Not that I knew of.

> Seems customization as well as additions could be more easily handled.

As you notice yourself a the end of your message installing a sqlite
client isn't easier than launching your favourite texteditor.

Right now custom strings and stock strings are clearly separated. If you
store them in the database and update the table on custom changes you'll
be in trouble once you want to roll back to the original values.

> Probably faster loading as well, rather than parsing a text file that
> will likely keep growing as new features and interface elements are
> added.

This isn't an issue as it's done once on startup, or on language change.
It takes no time.

> The only real downside being that they're not as easily edited
> without creating some type of (web) interface to the database.

I still could/would change my StringEditor plugin to work with it.

--

Michael

-----------------------------------------------------------
Help translate SlimServer by using the
StringEditor Plugin (http://www.herger.net/slim/)

mherger
2005-06-23, 23:52
>> Probably faster loading as well, rather than parsing a text file that
>> will likely keep growing as new features and interface elements are
>> added.
>
> This isn't an issue as it's done once on startup, or on language change.
> It takes no time.

Just to give you a number: Slim::Utils::Strings::init() took 1.7 seconds
on a Pentium 200, running from compact flash (which is considerably slower
than any recent harddisk), or 0.45 seconds on a AMD/1000.

--

Michael

-----------------------------------------------------------
Help translate SlimServer by using the
StringEditor Plugin (http://www.herger.net/slim/)

JJZolx
2005-06-24, 15:40
Custom files should only contain what you want to change. Don't copy the
whole file to do your changes. You custom strings will always overwrite
the stock strings. If the latter changes, you won't notice it as you'll
still see your own version.

I wasn't aware of that. I suppose then, that it's probably also unnecessary to have all language versions of the custom strings in the custom file?


> Is it planned to move these strings into the database at some point?[/color]

Not that I knew of.

> Seems customization as well as additions could be more easily handled.

As you notice yourself a the end of your message installing a sqlite
client isn't easier than launching your favourite texteditor.

Easy to edit if you know what you're looking for. I haven't used your plugin, but I imagine it gives some kind of explanation of the use of each string. Just having easy access to the data doesn't necessarily make it easier to edit.


Right now custom strings and stock strings are clearly separated. If you
store them in the database and update the table on custom changes you'll
be in trouble once you want to roll back to the original values.

There are several ways to approach that. You could have a column for default values and a column for custom values. Or two parallel tables. Or you could flag as custom those strings that have been changed. Keep the default values in a text file so that you could grab the original if you wanted to roll back.



> Probably faster loading as well, rather than parsing a text file that
> will likely keep growing as new features and interface elements are
> added.

This isn't an issue as it's done once on startup, or on language change.
It takes no time.

Everything takes time. If it's very fast that's great, but it would likely be faster reading the data from the database. As I said, this file is only going to grow larger and larger. If all of this text is loaded at startup and held in the server's memory then that seems even more of a reason to put it in the db. You'd have very fast access to the text on the fly.


I still could/would change my StringEditor plugin to work with it.

It would probably be much easier for your editor to work with the data in the db rather than a delimited text file.

mherger
2005-06-25, 10:28
> I wasn't aware of that. I suppose then, that it's probably also
> unnecessary to have all language versions of the custom strings in
> the custom file?

Oh yes, it is indeed! A minimal custom strings file will contain only
two lines: the string token and your string (preceeded by
tab-languagecode-tab).

> Easy to edit if you know what you're looking for. I haven't used
> your
> plugin, but I imagine it gives some kind of explanation of the use of
> each string. Just having easy access to the data doesn't necessarily
> make it easier to edit.

It's true that I'm using it in another way than you do: I have the
explanation in the form of the original english string :-).

> > This isn't an issue as it's done once on startup, or on language
> > change. It takes no time.
>
> Everything takes time. If it's very fast that's great, but it would
> likely be faster reading the data from the database.

Are you going to read the file once at startup or everytime you need a
string? If it's at startup only, the time needed (as my numbers showed)
is negligible.

> As I said, this
> file is only going to grow larger and larger. If all of this text is
> loaded at startup and held in the server's memory then that seems
> even
> more of a reason to put it in the db. You'd have very fast access to
> the text on the fly.

I think it can't get much faster than retrieved from a hash stored in
memory (which is the case right now). But we could reduce memory
consumption (at the cost of speed), that's true. BTW: up to 5.x all
strings for all languages were kept in that hash... Now it's only your
language plus english (failback).

> > I still could/would change my StringEditor plugin to work with it.
>
> It would probably be much easier for your editor to work with the
> data in the db rather than a delimited text file.

I don't work with the file directly, but with the standard methods to
retrieve strings (Slim::Utils::String.pm). Only when writing out
changes I use my own methods.

--

Michael

-----------------------------------------------------------
http://www.jo-sac.ch - JO-SAC inoffiziell!
http://www.herger.net/photo - mein kleines Photoalbum