I'm using json_parser and we have many, many files that have trailing commas. This breaks the current implementation because the official JSON spec does not prohibit trailing commas. Rather than write a custom parser or impose a change on our developers, it would be nice to have an option to enable relaxed mode.

Hello.
I do not understand the reasons for the error. Maybe it's easy and you can tell?
`root@Kholodkov-VM:/home/andre/serge/serge/t/data/engine# serge import Pootletest.serge

*** /home/andre/serge/serge/t/data/engine/Pootletest.serge ***

*** [raketa] Process git file project ***

Path to source resources: [/home/andre/translations/Pootletest/vcs/docs]
Path to localized resources: [/home/andre/translations/Pootletest/%NAME%.%EXT%]
Languages: [en,ru]
DB source: []
Preloading cache for job 'raketa' in namespace 'Pootletest'...
Can't call method "prepare" on an undefined value at /home/andre/serge/serge/bin/../lib/Serge/DB.pm line 286.`
My Pootletest.serge file http://pastebin.com/bbNmZAdw

Hi there,

In my xxx.strings file, I have one string, for example,

/* Button's title */
"Button.Title"="Hello 
world!"

Note: Xcode supports this style.

I cannot get the "Hello \n world!", what should I do for this ?

I'm new to Pootle. Everything I have read, and my short experience tells me, that I need a templates/blah.pot file for =pootle update_store= to correctly load my new translations. I can't find any mention of that in Serge's documentation or source code. How are you getting translations into serge?

My current directory is just 'serge_test_proj/jpn/blah.po' and that isn't getting picked up. When I add a .pot file by hand, it does.

The root of the data in our YAML files is the locale of the data:

en-US:
  actual_data:
    starts: one level down

When we import this data using parse_yaml, it creates a string with en-US/actual_data/starts as its path. It seems like this should be actual_data/starts. I’ve been poking around in the documentation and code, and I don’t see an easy way to make this happen. I’m happy to modify the plugin to take an option specifying a path to traverse in each file, but I wanted to ask if I’m going about this the wrong way before I started.

(Also: our JSON data is similarly structured, so I’m hoping there is an easier way)

We currently store our translations in YAML files, but I see this being an issue for Java properties, JSON, or any other hierarchical format.

Ideally, the separator between levels is irrelevant:

deeply:
  nested:
    key:
      structure: Separators should be irrelevant.

It should not matter if this is represented as deeply.nested.key.structure or (as Serge represents it) /deeply/nested/key/structure.

However, we have some legacy files where many of the keys are ARE the phrase to be translated[*]. The periods have been replaced with underscores, but many of these keys have /’s in their names. I am not sure the best way to proceed. It is not feasible to replace all of these phrases in these files and the code that relies on them[**].

I was thinking of looking at making the separator in Serge be configurable (and defaulting to /), but I wanted to ask you your thoughts before I dove into what could potentially be a far-reaching change.

So, any guidance or thoughts you might have on this problem would be appreciated.

[*] This was done with much consternation and hand-wringing to work around a limitation in a service which is no longer relevant.

[**] Though once we have things running through Serge it is likely we will take on a project to work through deprecating them.

If serge or any of the tools are symlinked, they won't find their libraries. The problem is that it uses File::Spec::Functions::rel2abs() function that doesn't canonize symlinked paths. Using Cwd::abs_path() should fix the issue.

Currently plugin accepts only one command parameter. It would be convenient to have multiple command parameters supported. Current workaround is to define several callback plugin sections for run_command plugin, each having single command parameter.

Custom sync plugins can be created, but there are two hard-coded references to Pootle. The logs become misleading when using a non-Pootle back-end.

https://github.com/evernote/serge/blob/ba6b1b11ebd46eba3522ebe646d4bbbe0a2f0c10/lib/Serge/Sync.pm#L116

https://github.com/evernote/serge/blob/ba6b1b11ebd46eba3522ebe646d4bbbe0a2f0c10/lib/Serge/Sync.pm#L143

Hi,

We're working on integrating serge into our development process and in general things are going very well. However, we're running into an issue where serge is escaping our escape characters when processing Apple .strings files with the .strings plugin.

It seems like serge is importing the files from our codebase with the escape characters intact, but then escaping our escape characters when we run localize.

Is there (or could there be) a way to turn off character escaping?

Created an issue to track the discussion of a change I plan to work on.

I'm writing a new parser plugin. I see 50-100 lines of email notification code duplicated across most plugins. I'd like to factor that out into a reusable utility.

I plan to use Role::Tiny. It has been around for years, has few dependencies, and was recently updated. I initially investigated a solution that didn't require additional modules, but there was no clean and easy way to execute code after init and other parent methods. I also didn't want to introduce another base class, PluginErrorReporter.

I will also create a more generic Mailer role to be used by ErrorMailer and Completeness.

I'll plan on creating a PR for the above enhancements plus Serge::Engine::Plugin::parse_csv.

Feedback is appreciated.

When running serge <command> <config-file>.serge, the configuration file might be inheriting key-values from some common or master configuration file, and one might need to browse files manually to realize of the entire set of options in effect.

While a standalone Config::Neat command already supports displaying the expanded/interpreted configurations, it probably makes sense to integrate/wrap it in a simple serge command such as serge show <config-file>.serge. Bonus points for coloring the syntax in the console and running that through a pager.

Creating an issue to track discussion related to parse_csv, a module I'm working on.

It's mostly complete now. I'm just working on adding comments and a few more corner cases to the tests.

Notes:

• It is basically key-value, stored as CSV.
• I didn't create it with the intent of using multiple columns as a translation source because that's not what I need it for, but I wouldn't rule it out in the future.
• My usage assumes the key column values are unique within the .csv file, but I will try not to code that assumption into the plugin, if possible.
• It will preserve extra columns in the CSV file.

An example config:

        parser
        {
            plugin            parse_csv
            data
            {
                column_key    KEY
                column_string STRING
                # Also column_context, column_comment, delimiter
           }
         }

Feedback is appreciated.

If one defines a language with uppercase text in it, e.g. de-DE, then Serge can't properly find a translation in a database.

While it's recommended to use ISO language codes (which are lowercase), Serge should support any kinds of strings as language names.

This is an issue to discuss the Perforce VCS plugin I'm currently working on.

Notes:

• No new Perl dependencies are required.
• I haven't tested on Windows, but I didn't use any OS-specific syntax, so I expect it to work without change.
• I decided to use the command-line p4 program and not the Perl API because the former will be much simpler for Serge users. The P4 Perl API is only available on Perforce's site, and it requires that you download or compile the p4 binaries separately before making the Perl module. The binaries required are 4 years old and only available by special request from Perforce's help desk.
• This plugin will require Perforce 2012.1 or later because it depends on the reconcile command.
• Each repository_url is expected to be a p4 filespec (eg. //depot/some_project). It will sync all files under that path by default, but the user can add additional filespecs with wildcards in the config file to selectively sync files.
• A client will automatically be created. Its name will be customizable in the configuration.
• I have something working reliably during brief testing.

Feedback is welcome.

I'm having trouble parsing php-files. Some of my output:

=====^
/**
 * ContentBlockUnion.php
 */
namespace Sigura\Mods\Industries\GraphQL\Unions;
 at /usr/lib/x86_64-linux-gnu/perl5/5.22/XML/Parser.pm line 187.

    _namespaced/GraphQL/Unions/VerzekeringsnemerUnion.php
        WARNING: File parsing failed; the file will not be processed
        Reason: unclosed token at line 1, column 6, byte 6:
<root><?php


=====^
namespace Sigura\Mods\Industries\GraphQL\Mutations\Betrokkenen;

use \Youshido\GraphQL\Type\NonNullType;
use \Youshido\GraphQL\Type\Object\AbstractObjectType;
 at /usr/lib/x86_64-linux-gnu/perl5/5.22/XML/Parser.pm line 187.

    _namespaced/GraphQL/Mutations/Betrokkenen/DeleteBetrokkeneMutation.php
        WARNING: File parsing failed; the file will not be processed
        Reason: unclosed token at line 1, column 6, byte 6:
<root><?php

My output from serge localize myproject.serge: output.txt

The output from "serge sync" is pretty verbose right now. The important parts get lost in the debugging information. Reformatting would help, but Log::Log4perl with log levels would be best. It would allow me to reuse other logging infrastructure at my company.

Obviously not high on the list of priorities, but nice to have. I could submit a pull request for this in the future if/after we roll Serge out.

In my environment, the parser tests (specifically for parse_yaml & parse_json) are unstable. They fail most of the time, but on occasion will pass.

I thought this might be due to the deliberate randomization of hash keys in 5.18, and it seems (anecdotally) that setting PERL_PERTURB_KEYS=0 does appear to help some of the tests, it does not guarantee a successful run.

Am I right in assuming these tests are consistent for you, and there is something else in my environment causing this issue?

Hello,

I was trying to perform a push ts with serge to push the files to pootle but then it came back with this obscure message:

Updating Pootle's internal database from .po files...
Running 'prepare.sh update_stores --project=test'...
Exception occurred while processing configuration file:
Exit code: -1

The error seems very obscure to me as it is not pointing out what could have went wrong with the configuration.

Here is the config

sync
{
    ts
    {
        plugin                  pootle

        data
        {
            manage_py_path      prepare.sh
            project_id          test
        }
    }

    vcs
    {
        plugin                   git

        data
        {
            # (STRING) Absolute path to local folder where local
            # checkout will be stored.
            local_path           pootle

            # (STRING) Path to a single remote repository
            # to sync with local `data_dir` folder
            remote_path         some_git_ssh_link

            # (BOOLEAN) [OPTIONAL] should the newly generated
            # files be added to the remote repository automatically?
            # (YES or NO, defaults to NO)
            add_unversioned      NO

            # (STRING) [OPTIONAL] Commit message
            # Default: 'Automatic commit of updated project files'
            commit_message       Automatic commit of updated project files

            # (STRING) public committer name
            name                 Test i18n

            # (STRING) commiter's email address
            email                [email protected]
        }
    }


    # other sync parameters
    # ...
}

jobs
{
    # job 1
    {
        id                      pootle.translate.i18n
        name                    TESTPOCV4
        optimizations               YES
        active                      YES
        source_language         en
        destination_languages   es fr
        debug                   YES
        db_source               DBI:SQLite:dbname=./translate.db3
        db_namespace            test
        source_dir              /path/to/my/translation/en
        source_process_subdirs      YES
        source_match            \.po$
        #source_match            \.json$

        parser
        {
            # (STRING) Parser class name.
            # See Serge/Engine/Plugin/parse_*.pm files
            plugin                  parse_pot
        }

        #parser
        #{
        #    plugin               parse_json_keyvalue
        #}

        ts_file_path                /path/to/my/translation/%LOCALE%/%FILE%
        #reuse_translations          YES
        output_encoding             UTF-8
        output_lang_files           YES
        output_default_lang_file    NO
        output_file_path            /path/to/my/translation/%LOCALE%/%FILE%

        # other job parameters
        # ...
    }

    # other jobs
    # ...
}

I should point out that my translation are under a specific project so I symlink that folder in my pootle translation directory (as pootle usually has its own translation directory)

Can anybody help at all ?

Running tests in a CI server and reporting the results to PRs and using a badge in the README would give greater visibility to them. This also gives greater confidence to potential users and developers.

Using 'parse_json_keyvalue' parser, the output file comes out as with 'key' value alphabetically sorted.
Is there a way to keep the original English order as is?

I don't think it will break the function, but for troubleshooting, visual diff, debugging and etc with English source file, it would be great if we can keep the original English order as is.

Hi,

We are looking into potentially using serge as part of our continuous localization platform, and we are utilizing the basic SOA architecture with strings stored in DB(Mongo) that needs to be localized. Wonder is there a good way to handle that using serge?

What we have been planning is:

1. When service A persist strings in the DB that needs to be translated, embrace it with certain marker.

2. Having a cron job running in the backend constantly pulling the strings that needs to be translated from DB to localization resource file that will be feed into the translation workflow.

3. When service B calls GET request to service B for retrieving certain content with strings need to be localized, service B need to pass the locale info as part of the request. In the business logic of Service A, it queries the DB first, and for the fields that have the localized mark, ask the translated resource file to get the translated string based on local.

Wonder how do you achieve similar localization workflow in Evernote within Service-Oriented architecture? Is anything serger can help to make it easier?

Thanks!

When reuse_uncertain mode is disabled, Serge::DB::Cached::find_best_translation() just detects that there are some translations for the string in the database and passes the call to Serge::DB::find_best_translation(). This method is slow, however, and it is run on each localization cycle for items that need to be translated but have multiple variants of translations in the database.

To optimize for this scenario, we can cache the number of translation variants for each source string in Serge::DB::Cached::preload_strings_for_lang() and then account for that number in Serge::DB::Cached::find_best_translation(), quitting early if reuse_uncertain is off, and there are multiple variants of the translation.

Take a PO file such as:

msgid ""
msgstr ""
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

msgid "Foo\r"
msgstr ""

msgid "Bar\r\n"
msgstr ""

and place it in a job's source_dir, specify the parse_pot parser and define some destination_language.

Run serge localize to run a localization step, hence generating the resources to be translated, as well as the localized resources.

Both the translated and the localized resources will contain escaped \r characters, i.e. \\r, while \n characters are kept as they are. One would expect \r characters to be kept as they are too.

Unfortunately, I still have issues trying to make serge work. This time I'm not quite sure what the workflow for translation .po files could be. Can you please help me to connect the dots.

Repository layout

We have a repository with the following structure:

en/LC_MESSAGES/messages.pot
...
ar/LC_MESSAGES/messages.po
bg/LC_MESSAGES/messages.po
ru/LC_MESSAGES/messages.po
...

The en lang plays the role of a source language. Files in lang/LC_MESSAGES/messages.po are mostly translated.

Serge configuration

Serge config file looks like this: my_project.serge. I put my repository inside repos/my_project, and translation files which Pootle operates with, live in translations/my_project.

What I expect to have

At first sight, it looks a bit silly that we make Serge to parse .po files and store it in a different directory with the same format. But my initial goal was to make Serge apply changes from en/.../messages.pot to lng/.../messages.po for every language. Previously we did this job with pootle update_against_templates, but according to new documentation, it's up to third-party tools to do this. I expected Serge to help me with that :)

What I tried to do

Simple serge pull and serge localize didn't help. Quite the opposite, it replaced all translations in all files with msgids. The diff excerpt (result of the serge localize work).

@@ -38,7 +36,7 @@ msgstr ""
 #: tmpl/user/reset_password.mako:24
 #: tmpl/user/welcome.mako:53
 msgid "Best regards,"
-msgstr "С наилучшими пожеланиями,"
+msgstr "Best regards,"

I rolled back everything to initial state and removed the SQLite "translation memory" database. My next step was to try to import strings first. Results of the serge import weren't very satisfactory either.

Looks like Serge populates database with original strings for every language. The result of serge localize was the same as in previous case.

What should I do?

I tried to make Serge work according to my expectations based on my best understanding of the Serge workflow. Can you please help me and tell me where I failed. Shouldn't I use Serge for that kind of work in the first place, or my workflow is wrong, or maybe there is a bug in Serge itself?

Grateful for any help. Ready to provide all sorts of extra information. Thanks!

%PATH% - file path including trailing path delimiter

In an android project work with serge serializer, the folder name is kind like "values-%lang%"
but %PATH% including trailing path delimiter with which %PATH%-%lang% only produce "values/-en"
how could I delete the trailing path delimiter when generating output file?

Attempting to use parse_yaml results in errors:

ERROR: Parser plugin didn't provide a key value in a callback. Importing translations with this plugin is not possible.

I believe this is because it is passing arguments to the callback in the wrong order. In particular it is passing the key path as the third argument, and Serge::Importer::parse_source_file_callback uses that argument as the hint.

parse_yaml is also only passing 5 arguments to the callback, which suggests to me it was written for a different version of the parser API.

Here's my configure file

/*
    Sample configuration file.
    Do not alter it directly; make a copy of the file first.

    This configuration file uses Config::Neat format.
    See https://github.com/iafan/Config-Neat for more information.
*/

sync
{
    ts
    {
        plugin                      pootle
        data
        {
            project_id              project1
            manage_py_path          /path/to/pootle/manage.py
        }
    }

    vcs
    {
        plugin                      git
        data
        {
            local_path              /Users/tropsci/serge_dir/serge_demo

            remote_path             https://git.oschina.net/liuwin7/serge_demo.git

            add_unversioned         NO

            commit_message          Automatic commit of updated project files

            name                    L10N Robot

            email                   [email protected]
        }
    }
}


jobs
{
    {
        id                          project1.cm-topsci.com
        name                        Sample job 1
        optimizations               YES
        active                      YES
        debug                       NO
        debug_nosave                NO
        output_only_mode            NO
        source_language             en
        destination_languages       zh de ja ru
        source_dir                  ./serge_demo/
        source_path_prefix          ``
        source_process_subdirs      YES
        source_match                \.strings$
        source_exclude              ``

        parser
        {
            plugin                  parse_strings

            data
            {
                #param1             value1
                #param2             value2
            }
        }

        normalize_strings           NO
        db_source                   DBI:SQLite:dbname=./translate.db3

        db_username                 l10n
        db_password                 secretword
        db_namespace                project1
        reuse_translations          YES
        reuse_orphaned              YES
        reuse_uncertain             NO
        reuse_as_fuzzy_default      YES
        reuse_as_fuzzy              ja
        reuse_as_not_fuzzy          de
        similar_languages
        {
            {
                source              es
                destination         es-419
                as_fuzzy            YES
            }

            # Vice versa
            {
                source              es-419
                destination         es
                as_fuzzy            YES
            }
        }

        ts_file_path                /Users/tropsci/serge/po/project1/%LOCALE%/%FILE%.po
        output_lang_files           YES
        output_default_lang_file    NO
        output_encoding             UCS-2LE
        output_bom                  YES
        output_lang_rewrite
        {
            no                      nb
        }
        output_file_path            ./%FILE%.%LANG%

    } 
}

My source directory tree:

serge_demo/
├── LICENSE
├── Localization_Serge_Demo
│   ├── AppDelegate.swift
│   ├── Assets.xcassets
│   │   └── AppIcon.appiconset
│   │       └── Contents.json
│   ├── Base.lproj
│   │   ├── LaunchScreen.storyboard
│   │   └── Main.storyboard
│   ├── Info.plist
│   ├── ViewController.swift
│   ├── en.lproj
│   │   └── Localization.strings
│   └── zh-Hans.lproj
│       ├── LaunchScreen.strings
│       ├── Localization.strings
│       └── Main.strings
├── Localization_Serge_Demo.xcodeproj
│   ├── project.pbxproj
│   ├── project.xcworkspace
│   │   ├── contents.xcworkspacedata
│   │   └── xcuserdata
│   │       └── tropsci.xcuserdatad
│   │           └── UserInterfaceState.xcuserstate
│   └── xcuserdata
│       └── tropsci.xcuserdatad
│           └── xcschemes
│               ├── Localization_Serge_Demo.xcscheme
│               └── xcschememanagement.plist
├── Localization_Serge_DemoTests
│   ├── Info.plist
│   └── Localization_Serge_DemoTests.swift
├── README.md
└── aa.strings

Why I cannot find the .strings files?
PS: My project is base on Xcode and is a iOS project.

I'm new to Serge. This week I have been reading through the docs, code, and presentations. From what I gather Translation Interchange File must be .po files. I was wondering if you're open to adding an option for xliff files, and how you think it would be best implemented in Serge.

Hi,

Can someone please share a config file that just pick up a resource file from local and output a PO file?
Still somewhat confused all the fields in configuration reference file and looking for some small sample config file that will help me to get started.
TIA.

It would be very neat if installation steps were reduced down to the bare minimum.

I ignore if there are any limitations from the technical level, but from the user perspective ideally one would run a single command that downloads and installs all required dependencies, along with making the serge executable available in the user's search PATH. If there was a post-install installation step that also generates docs that would be gorgeous.

The net result would be a vastly simplified installation experience with a truly easy way to start trying out serge.

I'm not familiar with UNIX base.
I started reading below page then got stuck in Step #3.
https://serge.io/download/#sel:ZGl2L2Rpdi4yL2NvZGUuMS9ALjE6MS0qOjQ0

Is there way to add 'Step 3. Install Dependencies for Windows' in this page for Windows user?

Running serge --version should provide version information for the serge executable. Just one line which says Serge x.y (plus a line feed) is really all what's needed.

serge IRC channel on Freenode. seems nobody on that .

So i post the question here.
Using the previous android_ios project working with serge, As the development of the android project is much faster than the ios project, so after the translation of android project finished, I would like to use all the translation in ios project.
By far, it seems that I have to create all the keys in ios project same with the android project, which is very tedious and huge work.
Can I generate all *.strings files from the *.xml files in order to get all the texts with serge?
Thank you.

When I installed and ran Serge, config_schema.serge is missing causing serge localize to error out. It appears it's not included when installing the module with ./Build install. I also noticed *schema.sql files.

I think the correct way to handle this would be to use share_dir in Build.PL and File::ShareDir.

Are you ok with using File::ShareDir? If so I'll try to put together a pull request.

I haven't forgotten about the tweaks to parse_csv or vcs_p4, but I'm trying to get Serge deployed here before I go back and work on those, hence this issue.

Currently plugin accepts only one message parameter. It would be convenient to have multiple message parameters supported. Current workaround is to define several callback plugin sections for append_hint_message plugin, each having single message parameter.

If I have a clean database and I run 'serge import' on a Japanese language file, then 'serge localize --force', is it expected that the source Japanese language file would be rebuilt as English? It's not as I would expect. I just wanted to check expected behavior before I start digging into code and my config.

Here is the situation, I have a Project works both on Android and iOS, I have tested translating my android project with serge+pootle .This is really awesome.
but how could I output the translated text with iOS format in another output folder which is under the iOS project path.

Owe to the new protection strategy on Mac OS X 10.11 EI Capitan and later, System Integrity Protection(SIP), user haven't the permission to write access the directory /usr/bin, even the root role.

So, Create a symlink to serge binary in the guide for the Serge installation on Mac is not correct.

Please correct it. Maybe the /usr/local/bin/ is a good candidate.

The current reuse_translations code is pretty loose. It will re-use translations even if it finds one string from a file of a different name in a different namespace with the same context.

What I would like is a way to limit reuse only to the same file in a namespace. Essentially, only reuse if all of the following are true:

• Namespaces match
• File paths match
• Contexts match
• Source strings match

I would need to modify find_best_translation() and add a new option to the job configurations: reuse_fairly_certain , or maybe make each matching criteria an option:

• reuse_requires_matching_namespaces
• reuse_requires_matching_filepaths
• ...

Would you accept a pull request for this?

Problem: when using database connection string like DBI:SQLite:dbname=~/path/to/translate.db3 on Mac OS X, DBI->connect() will fail to create the database file if it doesn't exist. Specifying the full path like DBI:SQLite:dbname=/Users/someuser/path/to/translate.db3 solves the problem. So let's expand ~ at the beginning of the file path with the value of $HOME.

After i fellowed what the serge.io says, I want use the command serge to verify the correction about my installation process. Unfortunately I got an error. Here's
Can't locate Config/Neat/Inheritable.pm in @INC (you may need to install the Config::Neat::Inheritable module) (@INC contains: /Users/tropsci/serge/serge-1.1/bin/../vendor/lib /Users/tropsci/serge/serge-1.1/bin/../lib /Users/tropsci/serge/serge-1.1/bin/../extlibs/lib/perl5 /Library/Perl/5.18/darwin-thread-multi-2level /Library/Perl/5.18 /Network/Library/Perl/5.18/darwin-thread-multi-2level /Network/Library/Perl/5.18 /Library/Perl/Updates/5.18.2 /System/Library/Perl/5.18/darwin-thread-multi-2level /System/Library/Perl/5.18 /System/Library/Perl/Extras/5.18/darwin-thread-multi-2level /System/Library/Perl/Extras/5.18 .) at /Users/tropsci/serge/serge-1.1/bin/../lib/Serge/Config.pm line 7. BEGIN failed--compilation aborted at /Users/tropsci/serge/serge-1.1/bin/../lib/Serge/Config.pm line 7. Compilation failed in require at /Users/tropsci/serge/serge-1.1/bin/../lib/Serge/Config/Collector.pm line 8. BEGIN failed--compilation aborted at /Users/tropsci/serge/serge-1.1/bin/../lib/Serge/Config/Collector.pm line 8. Compilation failed in require at /Users/tropsci/serge/serge-1.1/bin/../lib/Serge/Application.pm line 10. BEGIN failed--compilation aborted at /Users/tropsci/serge/serge-1.1/bin/../lib/Serge/Application.pm line 10. Compilation failed in require at ./serge line 12. BEGIN failed--compilation aborted at ./serge line 12.
what's wrong with it？

I install Pootle in this way .

Could please give me a script for the manage_py_path?

ps Pootle installation

In a *nix environment with bash as the interpreter, when one runs git help <command> (or git command --help), it outputs what looks to be a man page. It would come handy if the output used a pager (such as less), instead of concatenating the output to the console.

git for instance uses a pager but allows customizing it via the GIT_PAGER environment variable, falling back to PAGER and then to less.

I also realize the probably intended purpose of serge help <command> is to open up a web browser with the local HTML docs for the given command. That might make sense in a Windows environment, although for *nix and server environments this is not definitely what one would expect. Maybe a flag can be added to try to trigger opening the docs in a browser.

Hi! Thanks for making serge Open Source!

When trying to import my current Android translations, I get back with a message

$ serge import myproject_android.serge

*** /home/pootle/serge-workspace/myproject_android.serge ***



*** [myproject_android]  ***

Preloading properties...
Path to source resources: [/home/pootle/serge-workspace/myproject_android/android/values]
Path to localized resources: [/home/pootle/serge-workspace/myproject_android/android/values-%LOCALE%/%FILE%]
Languages: [af,ar,bg,bn,bn_IN,ca,...,vi,zh_CN,zh_TW]
DB source: [DBI:SQLite:dbname=/home/pootle/serge-workspace/myproject_android.db3]
Preloading cache for job 'myproject_android' in namespace 'myproject_android'...

Updating database from source files...

Scanning directory structure...
Scanned in 0.000882000000000049 sec, 39 files match the criteria
        strings.xml
                        ERROR: Parser plugin didn't provide a key value in a callback. Importing translations with this plugin is not possible.

Is that right, you don't support import from Android XML files yet? Is there a workaround to populate the project with already translated strings?

I guess this is similar to #7.

$ serge import myproject.serge

*** /home/pootle/serge-workspace/myproject.serge ***

*** [myproject]  ***

Preloading properties...
Path to source resources: [/home/pootle/serge-workspace/repos/myproject/templates]
Path to localized resources: [/home/pootle/serge-workspace/repos/myproject/%LOCALE%/%PATH%%NAME%.po]
Languages: [ar,bg,bn,ca,cs,cy,da,de,el,en-gb,es,...,uk,vi,zh-cn,zh-tw]
DB source: [DBI:SQLite:dbname=/home/pootle/serge-workspace/serge.db3]
Preloading cache for job 'myproject' in namespace 'myproject'...

Updating database from source files...

Scanning directory structure...
Scanned in 0.000296 sec, 1 files match the criteria
        messages.pot
                        ERROR: Parser plugin didn't provide a key value in a callback. Importing translations with this plugin is not possible.

Is there anything I can do with this? Thanks!

Wondering if iOS .stringsdict files are not supported yet, not planned to be supported, or should be supported but aren't working. .strings doesn't catch these files (naturally) and I thought they were a pretty close fit for .plist, since the structure is very similar, but I get "ERROR: Parser plugin didn't provide a key value in a callback. Importing translations with this plugin is not possible."

What is the 'output_encoding' value for escaped Unicode (ASCII+UCN \U) and native encoding such as SHIFT_JS?

The configuration reference document shows below:

Sample values: UTF-8, UTF-16, UCS-2, UCS-4

Are these the only supported encoding or does Serge supports more? If so, can we have some more supported encoding somewhere or in this reference page?

While Serge can run without JSON::XS installed (JSON modules will fall-back to native Perl implementation), there are two caveats:

1. JSON and JSON::XS parsers seem to produce different results when it comes to item ordering; this produces different results at Serge side and fails tests.
2. Having no JSON::XS degrades performance.

So it's easier to just require JSON::XS for consistency.

Some tooling* apparently generates lines starting with #~ which causes the parser to fail at Serge/Engine/Plugin/parse_pot.pm line 168. Another instance that doesn't seem to be received well are lines like #| msgid... which are mentioned in the gettext docs (the aforementioned kind isn't).

Reproduced on latest master branch.

This is a really impressive tool. Great work!

* I suspect Lokalize