How to localize PHP source code which has embedded translatable strings? about serge

[iafan]

PHP/XHTML parser expects all XML nodes to be balanced, since it is a validating parser. This parser is used to localize text nodes in mostly static PHP (or pure HTML/XHTML) pages. You seem to try to localize a GraphQL library file (which by common convention has an opening <?php clause but no ending ?> one, so it is not balanced). But even putting this fact aside, this file doesn't seem to have any localizable content, so there's no reason to pass it through Serge at all.

If your question is how to exclude some files or directories from being processed by Serge, then look at source_exclude job parameter.

[Zombaya]

Well, I'm trying to process php-files which contain source-code for our application, which has translationable strings. It will indeed never have closing tags so it will not be unbalanced.

Is there a way to use xgettext since that is able to parse the php-files?

[iafan]

Serge was designed around the notion of localizing resource files, and what it does by default is generates localized copies of such resources. Since you have strings mixed with source code, and you definitely don't want that source code to be duplicated, you can address this in multiple ways:

Option A: manually extract localizable strings from sources into separate files. I recommend storing strings as PHP files with native associative arrays so that you don't have to write much code to use these files. This format is optimal for runtime, and you can use parse_hash parser for such files.

Option B: use xgettext or your own tool to automatically extract strings from the source code into your resource file. With xgettext the limitation will be that the resource files will be created in .po (.pot) format, and you will need to use PHP-s gettext library and other tools to compile resources into .mo format and then use them. The generated .pot files can be then processed by Serge using parse_pot parser.

Option C: write a custom parser for Serge to extract Gettext-like strings from your source files; this parser, instead of creating localized copies of source files, would generate one resource file per language (basically, dump data from Serge database in however format you like). This option is more involving (needs writing some custom code for Serge) but potentially allows you to do everything automatically on one step, without using external tools like xgettext.

My personal preference is Option A, since it gives you the full control over the result and allows you to disambiguate strings properly (because the same string in multiple places ideally should appear multiple times in resource files under different keys).

[Zombaya]

Thanks for the elaborate answer. I found it very helpful.

Before you answered, I managed to get option B working, but I'll take option A in consideration. Option C looks a bit daunting.

Any chance this information can be integrated in the documentation on serge.io? I found it a bit lacking for first time users. What I mean by this that it's not that easy to set up serge because there isn't a complete tutorial but only pages with parts of the solution.

[iafan]

Thanks for suggestions, @Zombaya! Serge documentation definitely will be improved over time. Your questions — and questions from other users — help me understand how other people intend to use Serge, and what topics need to be covered. And one of the motivations for me to provide such elaborate answers is that I will be able to reuse them later in the documentation.