scms locales are not automatically loaded

[SamK]

Mostly, we don't want the scm to head down the slippery slope of feeling it needs to compete with the tcz in terms of modularity, size, etc, therefore diluting it's main goal of being self contained.  Larger downloads are just part of that concept.

Even before the decison on handling locales was taken, the basic concept of an scm means that the download size of the scm will often exceed the size of a tcz alternative.  It is inherent within the design. Earlier posts seem to refer only to the compressed size of the download.

Upon installation to the file system, the app has to be uncompressed which results in RAM being used.  Increasing the size by incorporating locale files will exacerbate this further.  It may be particulary detrimental on older systems having smaller ammounts of RAM, or those with fixed amounts of RAM.

Might it be possible to accomodate the locale files within the scm while reducing the size used as described below.  The idea is raw and unpolished and meant to outline the concept rather than represent a finished method.

The scm contains three distinct parts:

• app
• app-locale
• loading script

The loading script loads app and app-locale in separate stages:

• stage1 load app
• stage2 load app-locale

After stage1 but before stage2, the loading script checks for a marker file or variable which indicates whether to conduct stage2

The marker file or variable might be created by use of a checkbox, or similar means, in the TC scm management GUI


If the above is practical it will:

• allow the scm to contain locale files
• allow the user to choose whether to load them
• enable the system to manage the scm as a single entity
  

Edit: fix typo

[curaga]

Upon installation to the file system, the app has to be uncompressed which results in RAM being used.  Increasing the size by incorporating locale files will exacerbate this further.  It may be particulary detrimental on older systems having smaller ammounts of RAM, or those with fixed amounts of RAM.

I'm afraid this is wrong. The only RAM used is the squashfs cache, which is a couple ten kb per mount. It doesn't depend on the size of the squashfs archive.

(regular file cache is of course on top, but that one can be freed if needed; squashfs cache can't.)

[vinnie]

Add dep in locales i think is the simpliest solution and package remain Light.

[SamK]

I'm afraid this is wrong.

My misunderstanding, thanks for the correction. 

[Jason W]

As I am totally unfamiliar with locale use, does having locales in share/locale in each scm even work in providing internationalization of each app without something exported in the app's wrapper in bin/?  I am assuming it does, but thought I would ask for clarification.

[curaga]

With natively compiled apps, yes. Can't say whether it works with the binary-hacked ones (././).

[Jason W]

I added ripperx-locale.tcz to the ripperx.scm extension, and it does work with "LANG=it_IT /apps/bin/ripperX", so the portable apps work with locales as well when the locale data is available and added to the scm extension.

[AbNoRMiS]

i downloaded and installed ripperx.scm
but did not find there locale files
but i found the remains of tcz extensions

/apps/ripperx/local/tce.installed/shared-mime-info
/apps/ripperx/local/tce.installed/gtk2
/apps/ripperx/local/tce.installed/gdk-pixbuf2

[Jason W]

/apps/ripperx/local/share/locale



The other files are small and harmless, I'll deal with them next time I have to edit the extension.

[AbNoRMiS]

tc@box:~$ find /apps/ripperx -name "locale"
tc@box:~$

there is nothing

[Jason W]

I see I tested it but forgot to upload it, will upload it tonight.

[Jason W]

Actually, the startup scripts in tce.installed usually need to be run or at least studied to see what needs to be done in initially setting up the extension.  So they are valuable to keep in the scm, as the tcz packages it was made from may get updated and their startup scripts changed, leaving no record of what was done in making the scm or what may have been missed and needs to be done in the case of troubleshooting an issue.  Best then to leave them in, they are small anyway.

[AbNoRMiS]

Add dep in locales i think is the simpliest solution and package remain Light.

dear vinnie
i lit up a little improved idea which i have outlined here
which also may be applied to self-contained modules

[AbNoRMiS]

Actually, the startup scripts in tce.installed usually need to be run or at least studied to see what needs to be done in initially setting up the extension.  So they are valuable to keep in the scm, as the tcz packages it was made from may get updated and their startup scripts changed, leaving no record of what was done in making the scm or what may have been missed and needs to be done in the case of troubleshooting an issue.  Best then to leave them in, they are small anyway.

i think need move the contents of these startup scripts to /apps/scm_name/config/install

[Jason W]

That would only be needed if there was a function that needs to be run every time the extension is loaded, which so far is not that case.  But for something that is needed to be run every time the extension is loaded, then yes, the routines would be put in the scm's startup script.