Skip to content

[Translation] Multiple problems #6765

Padam87 opened this Issue Jan 16, 2013 · 12 comments

8 participants

Padam87 commented Jan 16, 2013


We are having a hard time working with translations, mainly with the translation:update command.

Here is a list of issues (sorry, its gonna be a long one :)):

1. PoFileDumper

Po files should not be dumped without a header. It causes a lot of problems, including charset issues.

msgid ""
msgstr ""
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Project-Id-Version: \n"
"POT-Creation-Date: \n"
"PO-Revision-Date: \n"
"Last-Translator: \n"
"Language-Team: \n"
"MIME-Version: 1.0\n"
"X-Generator: Poedit 1.5.4\n"

This header is generated by poedit, a popular editor.

An absoulute minimum would be the first 4 lines, with an empty line after it.

2. PotFileDumper

POT is a nice addition to PO, it makes work easier. Should be available.

3. TranslationLoader

Translation loader should not be local aware.

$extension = $catalogue->getLocale().'.'.$format;
$files = $finder->files()->name('*.'.$extension)->in($directory);

As you can see, right now it only loads files for the given locale. Some formats (like POT) are not localized yet, and even localized formats should include all translation keys, regardless of the locale. Its very hard to keep track of your translation files if you have to do it manually, and working on an international app with 5+ languages.

4. TranslationUpdateCommand

4.1. Extraction

The command should try to extract keys from: twig, php, forms (I don't know if there any more)

Right now its only working for twig.

4.2. Bundle / Namespace

Right now it only works for a single bundle. It should work for namespaces as well. Furthermore, we sould be able to dump all translations into one file per locale. Translators are very confused by the per bundle approach, and they are right.

5. TwigExtractor

Fixed by 83382bc

Twig extractor should work with trimmed messages.

$catalogue->set($message[0], $this->prefix.$message[0], $message[1] ? $message[1] : $this->defaultDomain);

Should change this to:

$catalogue->set(trim($message[0]), $this->prefix.trim($message[0]), $message[1] ? $message[1] : $this->defaultDomain)

6. PR

I would gladly make a PR for this, in fact I did a first version a while back, #6191, I would just have to iron out some details. Unfortunately no response what so ever until now and it's not the kind of issue that you can just create a bundle for.

Any notes would be greatly appreciated.


borsi1 commented Jan 16, 2013




I've had an experience with a 6 countries application but we've used .xlf files with a bundle from JMS for giving the translators a nice interface (heavily customized after that).
So while I can't say anything about 1 and 2 I can say that:
3 should rather be a option based on the translation loader/even user maybe.
4 from experience ca vary but while we've had a different strategy to use the translation files / loading them, translators weren't too happy when they were translating the same string across multiple pages.
5 maybe there should be a command that trims the translations in the files / from the template. The loader/translation service shouldn't handle that as it's slow-ish
6 I could help out with it if you want and I think this should be considered even for 2.2 but the decision is not mine.


Padam87 commented Jan 16, 2013


3, I don't see why would anyone leave out a key on purpose, but an optional solution is good as well, anything to get this going...
4, We had those issues as well
5, I think speed is not a major issue here, this being a CLI tool mainly. But a command to trim the actual files would be great as well. Maybe a good addition to @fabpot CS fixer?
6, Thanks, if there is a chance the PR will be merged, I will definitely take you up on that offer :)






+1 mostly for point 1.
Every time I do a translation:update the charset gets lost and I have to correct every time each accented characters

goetas commented May 27, 2013

Should be a good idea allow a different directory structure?

Something like this ?

Resources/translations/[language]/[domain].[extension] instead of Resources/translations/[domain].[language].[extension]

goetas commented May 27, 2013

I've similar problems
1) +1
2) +1
3) +1
4.1) works very well

Take a look also here #4245

Padam87 commented Oct 6, 2013

Nr 5 fixed by 83382bc

@fabpot fabpot added a commit that referenced this issue Oct 9, 2013
@fabpot fabpot bug #9223 [Translator] PoFileDumper - PO headers (Padam87)
This PR was submitted for the master branch but it was merged into the 2.2 branch instead (closes #9223).


[Translator] PoFileDumper - PO headers

| Q             | A
| -------------  | ---
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #6765 - partially
| License       | MIT
| Doc PR        |

Po files should not be dumped without a header. It causes a lot of problems, including charset issues.

See #6765 / 1 for more info


e93bc50 [Translator] PoFileDumper - PO headers
goetas commented Dec 23, 2013

I've been following this issue for many months. It exposes similar problems to #4245.

Why not extract (remove?) from FrameworkBundle translation-writing parts (extract translations and write to files)?

As explained in #4245 (comment), JMS translation:extract do this things in a more consistent way.
Translation reading parts should remain inside FrameworkBundle.

Symfony member
fabpot commented Oct 5, 2015

Closing this meta issue. Feel free to reopen tickets for things that are not fixed yet.

@fabpot fabpot closed this Oct 5, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.