[2.1][Translator] Symfony translation process & gettext #4245
Comments
|
here i have a similar issue about Q2 (michelsalib/BCCExtraToolsBundle#25) |
|
Regarding Q4, i do not understand why should i extract translations from MO files and dump them inside a xlif file... |
|
@goetas Hi, I'm puzzled about the POT file import/export too. Q1: We can easily overload FileDumper::dump by PoFileDumper to make it dump to a Gettext file with all Contexts (Domains) and without a locale. Q2: When we have metadata into the Translation component (See Gettext.php providing for header and context info in #4249) we can also empty the translations. I'm in favour now to allow PoFile* to also process .pot files. Or do we have to extends these? I haven't study MoFile* classes. So changes are we need to refactor both into a GettextFile* then extend to MO, PO and POT? Q3, Q4: I'm not sure I get this one. When Q1 and Q2 are solved then having a MessageCatalogue we can dump all into on file? (Note: I'm only aware of Symfony Translation Component developing for Drupal CMS) Can you give me some (links to) command-line examples working in a Symfony only context. See my blog http://build2be.com/content/symfony-development to get the idea ;) |
|
Yes, POT files are simply extracted keys which can be used to create or update PO files, which can in turn be compiled to .MO files. It's completely base language agnostic. This certainly needs to be corrected. /cc @fabpot |
|
@clemens-tolboom |
|
currently i've implemented a POT dumper like this https://gist.github.com/2773646 for a general solution, should be done something like this: remove prefix functionality form |
|
@goetas You should really checkout my pull request #4249 as that adds a Gettext class providing for ie Gettext header and context support. You PotFileDumper look ok at first sight but:
What can I do with your Gist? It is now not testable, mergable, etc. Why not start a symfony clone? :-) |
|
tomorrow i will try to merge it into my clone |
|
@goetas has this been discontinued? |
|
unfortunately yes, it has been discontinued. currently i'm involved in a different project... maybe this winter i will put hands on this project.. |
|
If I get some time I'll try to tackle it then. |
|
Hi, @goetas. I will answer for Q2 and thus close issue michelsalib/BCCExtraToolsBundle#25. The use prefix was implemented initially to solve one single use case in some of my project : "I want to find with a simple CTRL-F all untranslated strings". At the time we decided to solve it using prefix. Afterward, I made the command public in the ExtraToolsBundle and pushed it in the symfony core. BTW, sorry for being so late on the topic. I will follow your next PR. |
This PR was merged into the master branch. Commits ------- 320fb6c [Translation] changed the MetadataAwareInterface method signatures 11ff433 [Translation] fixed CS in unit tests c40db35 [Translation] removed some code that is not done anywhere else in Symfony 63719a0 [Translation] created a new interface to avoid breaking BC 23e9e65 [Translation] fixed name 5607732 [Translation] added Metadata to MessageCatalogue Discussion ---------- [MessageCatalogue] Add Metadata to MessageCatalogue rework of symfony#4399 For improving the Gettext tools (PO, MO File Loader/Dumper) we need at least storage for their meta data. This patch allows for issues below to store and process ie Po Header, Po Header Pluralisation rule. Open - [[WIP]: Allow Drupal to use Translate component](symfony#4249) - [[2.1][Translator] Symfony translation process & gettext](symfony#4245) Closed: - [[Translation] Po/MoFileLoader parse plurization rules](symfony#3023) It has 1 TODO regarding addCatalogue: it now just override old values with new.
|
Q1: has not been solved... but as suggested by @clemens-tolboom, it can be extended & overwritten... At this moment i'm using JMS Translation Bundle that to things in a better way. Real question: Translation component (especially |
|
Thank you for this issue. |
|
Closing as this is super old, things have moved a lot meanwhile. |
I have a question about symfony translation process.
Currently it seems that symfony does not support POT files. I've added into my symfony fork a custom
PotFileDumper.There is some symfony design choices that i not understand:
Q1: Why
Symfony\Component\Translation\Dumper\FileDumperalways crate files as{path}.{locale}.{extension}? With POT files {locale} has not sense because POT file is not yet localized. (http://en.wikipedia.org/wiki/File:Gettext.svg)Q2: All message extractors (
Symfony\Component\Translation\Extractor\ExtractorInterface) uses a "prefix" to mark the untranslated string. This behaviour in a gettext environment (using tools like Virtaal or Pootle) is very boring, this because in gettext an untranslated string is an empty string (not a prefixed string). (http://www.gnu.org/software/gettext/manual/gettext.html#Untranslated-Entries)Q3: As i can see inside
TranslationUpdateCommand, translation can be extract only form"Bundle"/Resources/viewsdirectory. Also this is very boring because i can have a very large set of software components, and i will need to extract translations from them. ( php files that uses function with__('String to translate')syntax).Q4: The
translation:updatecommand is intended to extract messages from source, or to updateMessageCatalogueadding the untranslated strings?The text was updated successfully, but these errors were encountered: