PfSense® software translations with Zanata


  • Administrator


  • Banned

    1/ Is it somehow possible to import translated .pot file in there? (After spending a couple of days translating ~15K strings for UBNT on a similar platform, I’d rather not repeat that experience.)

    2/ Is is somehow possible to export the pfSense.mo for immediate use on pfSense from there, so that people can check how badly they’ve screwed the context?


  • Employee

    Yes and yes. Existing .po files can be uploaded and used as the basis for further translations. In fact the pt_BR, ja and tr files from the pfSense® source tree have already been uploaded. The .mo files may be downloaded as well as the .po files

    We plan to establish some threshold (50%, 75% ??) at which the translation becomes useful enough to be automatically incorporated into the build.


  • Employee

    Signing up to help with a translation

    If you would like to contribute your language skills to the pfSense® project, please:

    This will allow us to add you to the project as quickly as possible

    Thanks.



  • I ran into quite a few translations that need to be tested for context and proper use of all those %s.
    Is there quick way to copy the necessary files to my test KVM to see how bad it really looks? 🙂


  • Banned

    Well yeah that’s exactly what I meant by #2.



  • @doktornotor:

    Well yeah that’s exactly what I meant by #2.

    I know 🙂

    The .po file can be downloaded, but I cannot find any way to download the .mo file. Then again I haven’t really looked into what those files are doing and if maybe the .po is the only thing I need. Guess I will try to abuse the Brazilian language folder and see where that takes me.


  • Banned

    Well you need to compile it; IIRC the command was something like

    msgfmt -o lang.mo lang.po
    

    but that’s not exactly useful for people since that tool of course is not available on pfSense.



  • This seems to do the job for me:
    https://po2mo.net/



  • @athurdent:

    I ran into quite a few translations that need to be tested for context and proper use of all those %s.
    Is there quick way to copy the necessary files to my test KVM to see how bad it really looks? 🙂

    gettext() strings for translation that include multiple “%s” should have all the “%s” numbered:

    sprintf(gettext('Interface %1$s has IP address %2$s'), "LAN", "1.2.3.4")
    

    Then a translator can re-order the sentence if they need to in a target language where the whole sentence happens a different way around.

    I made a start on that in /etc with PR https://github.com/pfsense/pfsense/pull/3460
    and finished it with https://github.com/pfsense/pfsense/pull/3462

    Both those have been merged and I see that Renato just regenerated the “.pot” file. So I guess there are up-to-date translations strings waiting for any keen translators.



  • Thanks Phil!

    I guess something like this in firewall_rules_edit.php cannot be translated yet because it’s missing those gettext thingies?

    $group->setHelp(sprintf('Specify the %s port or port range for this rule. The "To" field may be left empty if only filtering a single port.',strtolower($name)));
    


  • @athurdent:

    Thanks Phil!

    I guess something like this in firewall_rules_edit.php cannot be translated yet because it’s missing those gettext thingies?

    $group->setHelp(sprintf('Specify the %s port or port range for this rule. The "To" field may be left empty if only filtering a single port.',strtolower($name)));
    

    PR https://github.com/pfsense/pfsense/pull/3464 should fix it.



  • Great, thanks!


  • Employee

    The correct syntax is actually:

    $group->setHelp('Specify the %s port or port range for this rule. The "To" field may be left empty if only filtering a single port.', array(strtolower($name))));
    

    setHelp accepts a second argument which is an array of arguments to be passed to sprintf. The first argument (format string) does get gettext()

    I want to see if we actually use that syntax anywhere, and if not (or few) I may update it to use a more conventional syntax.



  • You’ll know you’ve hit the bigtime when someone does a translation to Klingon.

    ghItlh bIngDaq ghItlh leghlu’ pa’ tlhIngan Hol


  • Employee

    Just pushed a change as described above. setHelp now likes the more conventional syntax:  e.g.:```
    setHelp("%d interfaces have been detected", $numIfs);



  • @KOM:

    You’ll know you’ve hit the bigtime when someone does a translation to Klingon.

    ghItlh bIngDaq ghItlh leghlu’ pa’ tlhIngan Hol

    Klingon 0.0001% complete now.
    Sadly there’s no Klingon, Elvish, Kölsch or FarCry Primal on Zanata. But you can always ask Steve to include Esperanto or Latin.



  • A few more bits of unneeded sprintf and gettext in setHelp removed by https://github.com/pfsense/pfsense/pull/3466

    You can all get busy with the Klingon translation now. Maybe I will have a go at English-Pirate en-PI.


  • Administrator

    Sadly, unless I’m overlooking something I don’t see an option for either Pirate or Klingon on Zanata

    Consider me timbers shivered.



  • Is there anything special about those?

    #: src/usr/local/www/system_advanced_network.php:186
    msgid "IPv4 address of Tunnel Peer"
    msgstr "IPv4 Adresse der Tunnelgegenstelle"
    

    It’s translated but it does not show. Might be my test setup, I just replace the Turkish .po and .mo files and reroot afterwards.

    I also believe that I have translated some Console messages a while ago, but they don’t show either.

    #: src/etc/inc/config.console.inc:43
    msgid "Press ENTER to continue."
    msgstr "Drücken Sie die Eingabetaste um fortzufahren."
    


  • I suppose new subforums will be created to match every additional language?



  • @KOM:

    I suppose new subforums will be created to match every additional language?

    Want to lure out those Klingons hidden all over earth? Neat.

    If memory serves Gonzopancho once said that he only creates forums for languages he has someone for to speak/understand.


 

© Copyright 2002 - 2018 Rubicon Communications, LLC | Privacy Policy