Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    tariver
    @tariver
    @iafan OK, thanks you for your help. I'll be AFK soon too, getting late here
    tariver
    @tariver

    Hello! Sorry to bother you again but I'm stuck again, can you help me out please.

    I successfully did serge pull --initialize and files from repository are in /var/serge/data/vcs/mapsurfer/conf/i18n
    Theare are ru, de and en folders inside this folder and auth.properties in each of this folder. The path is correct and the files are there, i checked.

    In config file I have:

    source_language             ru
    destination_languages       en de
    source_dir                  /var/serge/data/vcs/mapsurfer/conf/i18n/ru/
    source_match                \.properties$
    source_process_subdirs      YES

    But I still got No files match the search criteria error when I run serge localize mapsurfer.serge

    Here is the output:

    Tab symbol at config line 178 position 1 (replace tabs with spaces to ensure proper parsing of multiline parameters) at /usr/local/share/perl/5.24.1/Config/Neat.pm line 330.
    Tab symbol at config line 179 position 1 (replace tabs with spaces to ensure proper parsing of multiline parameters) at /usr/local/share/perl/5.24.1/Config/Neat.pm line 330.
    
    ### /var/serge/data/configs/mapsurfer.serge
    
    
    Running the translation framework...
    
    
    
    *** [mapsurfer] "MapSurfer" ***
    
    *** OPTIMIZATIONS DISABLED: job definition has changed (or job is ran for the first time) ***
    Source dir: [/var/serge/data/vcs/mapsurfer/conf/i18n/ru]
    DB source: [DBI:SQLite:dbname=/var/serge/data/db/translate.db3]
    TS file path: [/var/serge/data/ts/mapsurfer/%LOCALE%/%FILE%.po]
    Output path: [/var/serge/data/vcs/mapsurfer/conf/i18n/%LANG%/%FILE%]
    Destination languages: [de,en]
    Modified languages: [de,en]
    Preloading cache for job 'mapsurfer' in namespace 'mapsurfer'...
    
    Updating database from source files...
    
    Scanning directory structure...
    Scanned in 0.000469 sec, 0 files match the criteria
    Exception occurred while processing job 'mapsurfer': No files match the search criteria. Please reconfigure your job at /opt/serge/serge-1.4/bin/../lib/Serge/Engine.pm line 466.
    
    'localize' step took 0.013958 seconds
    
    Sync complete. 1 job in 1 configuration file was processed
    1 job ended abnormally

    I was wondering why it is so. Am I missing something?

    Igor Afanasyev
    @iafan
    @tariver just a sanity check: what does ls /var/serge/data/vcs/mapsurfer/conf/i18n/ru give you?
    I know you double-checked all this, but still...
    tariver
    @tariver
    ls /var/serge/data/vcs/mapsurfer/conf/i18n/ru
    alert         datastore   error      form        geoserver  layers      organization   talitrum    validate
    auth         datatables  featureBBox  forms        groups       leftPanel   parameter      token    xls
    auth.properties  date         features      geoCoding    image       map           rectangleDraw  tracking
    creationLayer     default     filters      geodatastore    jReports   monitoring  request          upload
    customField     eis         fixedLink      geom        layer       objects     rule          user
    These are localisation files
    They are without extension so at first I thought that maybe I did the regexp wrong so I renamed one of them to be with an extension (auth.properties)
    @iafan No problem, everybody sometimes misses a simple thing. :)
    Oh, and my parser config is
           parser
            {
                # (STRING) Parser class name.
                # See Serge/Engine/Plugin/parse_*.pm files
                plugin                  parse_properties
    
                # [OPTIONAL] Plugin data. Each plugin may have specific parameters
                # inside the `data` block. See the documentation for each specific
                # plugin for more information.
                data
                {
                    /*
                    (BOOLEAN) [OPTIONAL] Should single quotation
                    marks be escaped in localized files?
                    (' => '')
    
                    This option is needed because there are some
                    inconsistencies between different Java
                    frameworks in dealing with escaped quotes.
    
                    Default: NO
                    */
                    escaped_quotes   YES
                }
            # .properties files generally use Java encoding
    #        output_encoding     UTF-8 
            }
    Igor Afanasyev
    @iafan
    @tariver that's really strange... at this point, parser doesn't matter, as Serge thinks there are no files to parse.
    I checked for obvious mistakes (you know, when you use a Russian symbol instead of an English one, but they all look the same) — all seems to be good

    Would it work if you just say

    source_match                .

    ?

    tariver
    @tariver
    Let me try
    @iafan No luck. :(
    Igor Afanasyev
    @iafan
    can you send me in your full Serge config file in a private chat?
    tariver
    @tariver
    Sure
    Waqar Ali
    @aliw77
    Need help in making serge.io take my resource json and create a source language .PO file with keys that can then be sent over to the translation service. It creates an empty target language file, no source .po file
    im trying to use integration with Locize, which needs a .PO file with keys/strings as a source, but i am unable to get these
    Igor Afanasyev
    @iafan
    @aliw77 Serge creates both .po and target localized files. Do serge localize --force and check the output — Serge will print what .po files it creates and where. The output path for .po is controlled by ts_file_path.
    Waqar Ali
    @aliw77
    @iafan , serge localize --force generates only po file for the target language, not the default (en); so locize doesnt get an opportunity to create missingn keys during sync process as it is expecting the en-US to have the .po file
            source_language             en-US
            destination_languages       es-US
    ...
            output_lang_files           NO
            output_default_lang_file    NO
    Igor Afanasyev
    @iafan
    @aliw77 if you have en as a source, you can add en-us as a target — this way you will create en-us .po files as well. Also, notice that the sample locize project uses XLIFF, not PO, as a translation file format. I remember @dragosv (the author of those plugins) mentioning that some services work better when using XLIFF, so you might want to try that as well.
    Waqar Ali
    @aliw77
    Switched to xliff, still only getting es-US generated and not en, see config:
            source_language             en
            destination_languages       es-US en
    
    ...
    Generating translation files...
    
        document_945.json (forced mode)
    preload_translation_cache_for_lang(es-US, db) took 0.000139 seconds (0.000139 total seconds)
            Saving /Users/xxx/_dev/serge/data/ts/project_nomas/es-US/document_945.xliff (6477 bytes)
    generate_ts_files() took 0.05306 seconds
    generate_localized_files() took 7e-06 seconds
    *** [end] ***
    Igor Afanasyev
    @iafan
    well, that's the point: you have en as a source, and en-US as a target. This way you get your en-US XLIFF generated
    you can't use en both as a source and as a target, but as you add a different language (en-US), your translation file generates a bilingual file for this source-target pair.
    @aliw77 what I was trying to say about using XLIFF is not that it will change the behavior of Serge (the logic behind generating translation files stays the same regardless of XLIFF or PO), but that Locize might behave differently if you send XLIFF files there instead of PO, and may not require "source" XLIFF.
    both XLIFF and PO are bilingual file formats, so they require no source (and any TMS/CAT that requires a "source XLIFF" or "source PO" is doing it wrong). But maybe this is exactly where some systems work with one bilingual format correctly (e.g. XLIFF) and fail with another (e.g. PO)
    Waqar Ali
    @aliw77
    i get your point on PO vs XLIFF and no issues there
    and thank you so much for rapid responses, i really appreciate it!!!!
    en-US generated as expected by adding en-US
    Waqar Ali
    @aliw77
    THANKS!!!
    Waqar Ali
    @aliw77
    Is there a way to get an attribute from my Json resource file
    And use it as a hint in the xliff so translators have the context eg screenshot URL
    Igor Afanasyev
    @iafan
    @aliw77 it depends on the file format you use. There are some formats, like a JSON file for Chrome extensions (see https://serge.io/docs/plugins/parser/parse_chrome_json/) that allow one to provide both messages and descriptions for each of the string. If it's some custom JSON structure, you'll need to make your own parser. An easiest way would probably be to take the same parse_chrome_json parser, make your copy and tweak to your needs. Here is it's source with the actual "parser" lines highlighted: https://github.com/evernote/serge/blob/master/lib/Serge/Engine/Plugin/parse_chrome_json.pm#L124-L127
    feel free to share a sample of your JSON file if you need more input
    Waqar Ali
    @aliw77
    Having a challenge in getting keys properly parsed out of JSON and sent over to phraseapp, they show up as 'ids' instead of actual text keys, here are the screenshots of: 1) Json source, 2) serge parsed XLIFF which looks ok to me, 3) what i see when the file is pused to phraseapp, and 4) the serge parse settings
    CleanShot 2019-12-07 at 07.15.45.png
    CleanShot 2019-12-07 at 07.16.37.png
    CleanShot 2019-12-07 at 07.22.28.png
    Waqar Ali
    @aliw77
    image.png
    Igor Afanasyev
    @iafan
    @aliw77 for the JSON structure you have, you'll need to write your own parser. The parser that you use extracts just the text, and knows nothing about key names. See my suggestion above on how to approach creating a custom parser. Note that if you extract the key name, it looks like will appear in the 'Description' part in PhraseApp interface; IDs are auto-generated by Serge. Not sure why PhraseApp would want to display them in a list of segments instead of source text, since IDs by design are internal strings, not really suitable for consumption by humans.
    Igor Afanasyev
    @iafan
    @aliw77 ok, I think I see what the real problem with PhraseApp / sync is: looks like the source is actually empty. So you see only the [autogenerated] IDs, but don't have the actual source text present there (which also should be displayed next to the string IDs). I'll try to reproduce this on my side.
    Waqar Ali
    @aliw77
    i think i figured it out
    It is now fixed, i reran the parser and sync, and phrase now seems to be getting the segments in a way that the translator should be able to do the work, i am not sure why it didnt work the first time around, but so far, i haven't had to do any coding - just pure config stuff
    you are so VERY generous for helping, thank you!
    no action needed for now
    image.png
    Igor Afanasyev
    @iafan
    :+1: