I'm using openerp 7 and working on customizing invoice report.
I've made customization to the invoice report, using base_report_designer and OpenOffice. So template I work with is an *.sxw file.
I wonder how to translate custom terms I added in this report.
I've tried using the OpenERP interface (Settings -> Translations -> Application Terms -> Translated Terms), but it does not work.
Neither when I'm modifying the *.po file in account/i18n/fr.po.
Am i missing something in the translation process ?
Thank you for your help
Cheers
Try adding [[ setLang(yourInvoiceObject.partner_id.lang) ]] to your sxw file.
Related
Company i work develops a new programming language which will ease job of engineer. My job is to supply this language with a nice editor which is also involves code folding. I need to have custom code folding which is not include "{" and "}". I am working with Geany filetypes. I add new filetype. I want to fold some structure like below.
if %condition% then for each %element% in %range% do
%statement% %statement%
else if %condition% then end for
%statement%
else
end if
I know my language far from c type , however add such line to my code for enabling syntax coloring.
[settings]
lexer_filetype=C
Any kind of help will be appreciated.
I dont know exact answer but i know how i can dig it up. As far there is no an answer i am going to write how can the answer can be appeared. Using scintilla and its lexers can take us to solution of this problem. Both Geany and Scintilla documentations mention about support of that feature.
Under Debian :
cp /usr/share/geany/filetypes.c ~/.config/geany/filedefs/
chown myUser:myGroup ~/.config/geany/filedefs/filetypes.c
Edit the file. Under the section [lexer_properties] add the line:
fold.cpp.comment.explicit=1
Save the file.
Open geany. You are now able to put userfoldings using the default //{ and //} delimiters in c and in cpp. These do not influence your code because to c and cpp it are comments.
Using ZfcTwig for ZF2 and twig-gettext-extractor, I still cannot extract messages for translation from twig-files by poedit. I works if I used the formal twig keyword for translation {% trans(MY_TEXT) %} but not for the in-built view helper translate. {{ translate(MY_Text) }} does the translation but poedit is just ignoring it. For new twig files, I want as usual let poedit do the job....
Any ideas for a solution?
Maybe you need to edit catalog properties keywords to be visible for translations. Open PoEdit, go to Catalog -> Properties -> Sources keywords and add another keyword "translate". Here I attach an screenshot.
The problem is that the extractor you are using is just caching the files and running them through xgettext to extract calls to trans/translate/_/.. (keywords as suggested by Conti. Alas ZfcTwig will crosscompile calls to ZF2 plugins into plugin('translate')->__invoke('Your Text to be translated'). You could of course now add __invoke as a new keyword in poedit or whatever you favorite gui for using xgettext is, but it will now find all calls to all view helpers not just those to translate.
I ran into this problem myself and I have not come up with a satisfying solution. The Twig Gettext Extension looks promising in terms of writing your own customized POT-File generator that will handle translate and translatePlural view helper calls. Using the extension as is will bypass all translation from ZF2. ZF2 parses .mo files into an internal structure rather than using the php-gettext mod.
All in all I gave up on automated po(t) file generation for ZF2+ZfcTwig for now and am back to phpArray.
I have created a global data type, and use form renderer in a page to let user fill in the data and submit to website.
The default English is working fine.
now when I try to support the second language I run into issues. According to the composite documentation:
1.Add your empty localization file at ~/Frontend/CompositeForms/Renderer/Localization/, for example: Composite.FormsRenderer.de-de.xml
2.Copy the contents of the default Composite.FormsRenderer.en-us.xml to your localization file.
3.Translate the strings.
4.In ~/App_Data/Composite/Composite.config, under the section locate Composite.Plugins.FormsRenderer's add section and register your localization file
but ~/Frontend/CompositeForms/Renderer/Localization does not exist, and neither does Composite.FormsRendereren-us.xml exists.
is the documentation outdated? does anyone had experience with localizing form renderer on user defined data type?
thanks
The documentation IS outdated at the moment (and will be updated soon - thanks for pointing it out).
Do it in the following way on 4.0 or later:
Make a copy of ~/Composite/InstalledPackages/localization/Composite.Forms.Renderer.en-us.xml, changing the language/culture code from 'en-us' to your language's (e.g. Composite.Forms.Renderer.de-de.xml).
Translate the strings.
No need to change anything in ~/App_Data/Composite/Composite.config any more.
Hi I've got problem with translations in WP.
It looks like my WP is not reading translation files (.po/.mo).
I am using Roots theme which have from the beginnig support of localization
load_theme_textdomain('roots', get_template_directory() . '/lang');
However WP still output 'text' instead 'texttekst' in _e('text', 'roots')
I am also using a CodeStyling Localization which works quite well
And for changing locale Xili Language plugin.
Any help will be appreciated ;)
did you try to change in the wp-config.php file .
Just look for the line define('WPLANG', 'xx_XX'); ( line number 72 in my pack) and chagne xx_XX to your the language you expected. also don't forget to load the mo/po file.
a good software you would use is poedit to translate the text.
good luck
I have a database which I want to export as an iOS compatible PLIST.
The work around I have come up with is to create a calculated field which adds the tagged padding and header and creates a report using these fields. I then export the preview of the report as a PDF, open the PDF in Acrobat Reader, select all text, copy and paste into XCode which recognises the PLIST format and all works as expected.
Is there a better way of doing this? (This seems a really convoluted way of doing things, high chance of error, etc.) The Export as XML option looks promising but I can't seem to join the dots.
Two ways that I can think of to do what you're trying to do. The most elegant way is probably the XML with XSLT export which you suggest. If you don't already know XSLT, though, you might try the following -- it sounds like with the calculated XML line you've already created, like this would be a simple change to your database:
Create a single new global field, say outputXML
Create a script, say plistCreator
In the plistCreator script:
Set outputXML to ""
Go to the first record you want to export
Loop through every record putting your calculated XML line into outputXML (set field outputXML to outputXML & ΒΆ & calculatedXMLLine)
Go to next record, exit after last
Export Field Contents (note that this is a different command than Export) for outputXML
The cleanest solution is to use the export XML with an XSLT for transforming the output. You'll need to know a little XSLT to do this, or at least be able to customize the examples from FileMaker.