Menu

#1781 Externalize the script folder so that macOS users can access it

6.0.2
open
nobody
None
5
2026-01-12
2025-03-25
No

Hi,

I'm trying and run a script to extract text fom a file and I have the following problem:

  1. when I click on "Tool" then "Script", the pop-up window that opens is blank.

  2. when I try to define the folder for the script, I can't access the "Script" folder within the "Java" folder which is located in the "Content" folder of the application OmegaT (I'm using a Mac) because I can't right-click on the icon OmegaT to go past it and select the "Script" folder since the icon OmegaT is not a file.

  3. I tried and create my own "Script" folder elsewhere twice - for this exemple I had created it inside the Application folder - but when I run the script I get this error:

"Le script « /Applications/Script OmegaT/extract_text_content.groovy » est en cours d’exécution…
Une erreur s’est produite
javax.script.ScriptException: java.util.MissingResourceException: ResourceBundle (.properties file for localization) is missing."

I don't know what I'm doing wrong.

Thank you in advance for your help.

Discussion

  • Jean-Christophe Helary

    Ticket moved from /p/omegat/bugs/1289/

     
  • Jean-Christophe Helary

    • summary: Can't define folder for script --> Externalize the script folder so that macOS users can access it
     
  • Laurent Vimeney

    Laurent Vimeney - 2025-03-25

    Edit: "since the icon OmegaT is not a folder"

     
  • Damien Rembert

    Damien Rembert - 2025-05-04

    Hello, I think the issue here might be that the properties sub directory was not copied when copying the scripts directory. The properties directory holds localization files with the ".properties" extension.
    Removing that directory and trying to run a script gives me the same error.
    Could you check if copying the directory helps?

    I don't think there's any explanation in the docs regarding this directory. Is this something we should document @brandelune ? Or we could check if the directory is present and provide a clearer error message.

     
    • Jean-Christophe Helary

      I think you are right regarding the script launching issue. And we should document that, indeed.

      But the main issue is that in macOS the script folder is not accessible from the UI, even though it is packaged in OmegaT.app.

       
  • Jean-Christophe Helary

    @miurahr9 If we notarize the 6.0.2 OmegaT.app package, the OS will not allow anymore modifications to the contents of the OmegaT.app package.

    Hence, we need to relocate the scripts directory to an external location, as we did for the manual in https://sourceforge.net/p/omegat/feature-requests/1777/.

    Would you mind checking if you can handle that?

     
    • Hiroshi Miura

      Hiroshi Miura - 2025-09-19

      @brandelune Could you tell me which issue ticket for improvement of scripts folder? I want to start a topic branch for it.

       
      • Jean-Christophe Helary

        I can create a new issue, but this one (1781) is good in my opinion.

         
        • Hiroshi Miura

          Hiroshi Miura - 2025-09-19

          Where is a scripting specification?
          There is no content for script developers.
          https://omegat.readthedocs.io/en/latest/51.HowToWriteScript/

           
          • Jean-Christophe Helary

            How is that related to the script folder location that we are discussing here ?

             
            • Hiroshi Miura

              Hiroshi Miura - 2025-12-29

              I have raised the PR to add ADR of scripting feature, developer manual to explain SPI and folder detection, and explanation of sample scripts.
              https://github.com/omegat-org/omegat/pull/1835

               
  • Jean-Christophe Helary

    To notarize and publish OmegaT 6.0.2 we need to externalize the script folder, like we did for the manual folder.

     
  • Jean-Christophe Helary

    • Group: 6.1 --> 6.0.2
     
  • Jean-Christophe Helary

    We can imagine the following behavior at first launch:

    1. OmegaT checks if ~/Library/Application Support/OmegaT/scripts exists
    2. if it does not exist, OmegaT creates it
    3. OmegaT checks the contents compared to its internal contents
    4. if internal files are newer than local files, OmegaT asks whether the user wants to:
      • keep the new version
      • keep the old version
      • keep both
     
    • Hiroshi Miura

      Hiroshi Miura - 2025-12-29

      The initialization of scrips folder should be done in very early stage of the application start. It is impossible to ask user in the stage.

      We can take another strategy.

      • When there is NOT a folder, we copy a default scripts.
      • When there is a folder but there is no mandatory folder such as "application_start", we override by default scripts.
      • When there is a folder and there is a mandatory folder, we don't touch a folder.
       
      👍
      1
      • Jean-Christophe Helary

        The "event based action" folders are automatically created since 6.0, which means that pre-6.0 can have a normally populated script folder but without "event based action" folders.

        In that case, I don’t think overriding with default scripts in the good choice. That indicates a system that is being upgraded from pre-6.0 to 6.0+, in which case I think we should just add the non existing "event based action" folders.

        What do you think?

         
        • Hiroshi Miura

          Hiroshi Miura - 2025-12-30

          Thank you for notification of historical evidence. So what is practical (easy to implement and less problematic ) way to detect installation?

           
          • Jean-Christophe Helary

            Ok, so, the script folder is in the application folder for any version of OmegaT. Some users know that it can be in the configuration folder and put either all or a part of the scripts in the configuration folder.

            So the easiest and safest way to solve the issue is to check whether there is a script folder in the configuration folder. If there is none, install the scripts, if there is one, consider that it is user action and do not install anything.

            What do you think?

             
            • Hiroshi Miura

              Hiroshi Miura - 2025-12-30

              There is no script folder in the application folder in my OmegaT installation. There is script folder in the configuration folder which is created when OmegaT open the project.

              Addtional comment;

              I think there is incosistency in folder usage.

              SegmentExportImport class uses the OmegaT Configuration script Directory to exchange data with external scripts. It writes source.txt, target.txt, and selection.txt to this directory and monitors it for import.txt. However, users typically store their scripts in the User-defined Scripts Directory. If a script wants to interact with SegmentExportImport feature, it must know to look in the configuration directory.

               
              • Jean-Christophe Helary

                Sorry, it should have been scripts.

                The folder you mention is an old artifact that was used as a very primitive API to access segment contents.

                It has no relation whatsoever with what we call "scripts" here.

                The scripts folder is what we discuss here and it is by default in the application folder.

                Maybe it is time to rename that old script folder to something more explicit, and keep scripts for the OmegaT distributed scripts.

                 
            • Jean-Christophe Helary

              @miurahr9 did you consider this comment of mine in the current implementation?

               
              • Hiroshi Miura

                Hiroshi Miura - 2026-01-12

                I reflect your comment in the another PR#1859
                https://github.com/omegat-org/omegat/pull/1859/changes

                 
                👍
                1
  • Hiroshi Miura

    Hiroshi Miura - 2025-12-29

    A proposal of implementation for 6.0 branch has been raised as PR#1833
    https://github.com/omegat-org/omegat/pull/1833
    Please review it.

     

Log in to post a comment.

MongoDB Logo MongoDB