Hallo Fred, vous ecrit au Mon, 31 Oct 2022 08:27:22 +0000:
> OK, I get it ( had not see the .msetools folder because it was > hidden). What? You DID WRITE IT YOURSELF that you had created such a "folder" (I heartily dislike this denomination), and you presented a listing of its contents with your last posting! I thought to remember that it's usually created by mseide-msegui's installation process, but searching for it, I cannot find it mentioned anywhere there. So this might have been a wrong reminiscence of mine, and it should better go somewhere else. But that's not a problem, as this is STILL an unfinished - and perhaps even unwelcome, project. > So your idea is to split the po files into a "main_msegui" in > home/user/.msetools/lang and the "app_lang" po files. Yes, so to speak. (Although I aimed at .mo files, rather.) > Yes, of course usefull if you have mainy msegui applications > installed. I am not sure if I like it inside a hidden folder, I > prefer open things, but yes, why not. It pays even if you've only two of them installed. But yes, oh my, I realize the response: "but memory, especially disk memory, is so cheap these days"... I'm just not of this crowd. But it _also_ pays for the application writer - they will no longer have to create translations for all of the stock items over and over again, as they can rely on these being pre-translated and ready for use. (But if need be, they _can_ override them.) And what about your preference for open things - yes, gladly, what do you suggest? > Personnaly I prefer all in one (all files in directory of app) and This WILL NOT WORK on Windows, AFAIK - they explicitely deny an application to access data residing in the executable installation area, I heard. But it was said that there's a sneaky way how the system fakes such a possibility for unbehaving applications. > out-of-the-box (no files to be installed outside the folder of app) > but I know it is not the accademic Linux way. No, you know wrong here - it's perfectly possible for an application _a user installs in his home directory_. It's just not feasible (and not really useful, nor advisable) to do that for a system wide installation. Say, someone wanted to install the "msegit" and "msespice" applications for all users of his machine. Then, they are to be installed so that - the application executable should go into "/usr/bin" or "/usr/local/bin" - any application specific libraries go into "/usr/lib" or "/usr/local/lib" (doesn't apply for fpc applications) - and system-wide available application specific data usually reside in some application directory within "/usr/share" or "/usr/local/share". - Additionally, USER SPECIFIC data should go into an application dependent directory in his home directory, usually "hidden", if created directly, or under ".config", which is often predefined, or below a special (hidden) directory created by a "sub system" (like msegui, i.e. ".msegui", ".msetools" or some such) Sometimes, an application will be installed in the "/opt" hierarchy, under "/opt/<application specific directory>", that then contains its own "bin", "lib" and data subparts, has to manage these itself, and often provides links to the executable(s) within the common "/usr/bin" or "/usr/local/bin" directories. E.g. VirtualBox does it that way, or FreeCAD, if they're not installed by a distribution packet manager. > But you are right, splitting the po/mo is better way. Did you get it to _work_ now? You don't tell. -- (Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem) ----------------------------------------------------------- Mit freundlichen Grüßen, S. Schicktanz ----------------------------------------------------------- _______________________________________________ mseide-msegui-talk mailing list mseide-msegui-talk@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
