[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Localization issues - only thoughts



Hi Istvan;

On 10/18/07, Pongracz Istvan <..hidden..> wrote:
> Hi,
>
> I discussed some localization questions with some of my partners.
> It seems, we will have to modify the code/database to fit our national
> rules made by the government.

That does not surprise me.  There are a lot of localized rules for
various sorts of things and not off of them can be handled in the
current codebase properly.
>
> If we want to do this, it should be dangerous, because we will have
> problems with merging these modifications into the mainstream, due to
> that fact, they are national problems.
>
> If this will happen, we could run into that situation, maintaining our
> "national" codebase should start in its own way, generating a fork which
> will be behing LS and the gap will increase every week.

Not necessarily.  We already provide some features for maintaining
custom vertical solutions.  If we understand the problems, we can work
together to ensure maximum code reuse.  Obviously this requires that
we understand where the differences are, and keep up with eachoters's
changes.

>
> So, I would like to ask you (users, devels), what is your experiences in
> this field? (localization in non-english area with strict rules etc.)

I did some work on SL at one point to do some local rules.  It was a
pain, but it was possible.  Of course, making these portable between
versions in such a closed community was impossib;e.  I understand the
sort of issues you are likely to face and expect I have probably
already dealt with some of them in the past (work which is not a part
of LSMB due to the fact that it isn't sufficiently generally
applicable to my knowledge).

My suggestion is that we start by discussing where the problems you
have are, how generally applicable they are, and so forth.  We may
also find down the road that a given set of changes is required along
a sufficiently widespread group of users that we need to make the
behavior an official add-on maintained as a part of the core
distribution.

One clear example of this is the need in some countries to have
gapless numbering, and possibly the need to have gapless numbering of
attached printed documents.  Note that gapless numbering is not
required in the US and places considerable constraints on the software
in terms of scalability, performance, and workflow, so it would at
best be an optional behavior.

Finally, we are committed to helping LSMB be a viable base for
integrated solutions aimed at vertical or local markets.

>
> Is there an easy way or it is a known problem?
>

It is a known problem and we are committed to creating an easy way :-)
  I would expect that the time to start discussing your needs is now,
before we get the 1.4 development underway :-).
Best Wishes,
Chris Travers