FrontAccounting forum — Australian Translation - Purchase Orders not translated

Re: Australian Translation - Purchase Orders not translated

null@example.com (rodw) — Tue, 02 Mar 2010 20:19:05 +0000

Thanks Joe, After I went to bed last night, I realised that this PO is against a UK based vendor and in GBP which was probably causing it. It works as I expected with a local vendor in AUD. I think I'll leave it as the default for now.

I have purchased from the US as well in which case the references to VAT etc are meaningless. It might be useful to have a global flag that could be set to enable/disable doctext2 translation. I'd probably prefer to have all documents in my language.

Re: Australian Translation - Purchase Orders not translated

null@example.com (joe) — Tue, 02 Mar 2010 12:39:15 +0000

Hello again,
Does your supplier use the same currency as your own company? If not, the doctext2.inc texts are used.
I think that in your case, Rod, you could just copy doctext.inc into doctext2.inc so these two files are identical.
The reason for the doctext2.inc not to have gettextizised strings is that most countries not using English as their daily language often use English for export/other currency customers/suppliers.
So if you just copy the original doctext.inc into doctext2.inc and translate the strings in poedit that you need translated, then it should work. At least I hope

/Joe

Re: Australian Translation - Purchase Orders not translated

null@example.com (rodw) — Tue, 02 Mar 2010 12:27:39 +0000

Joe, I restored the default inc files and then started translating away. Invoices, orders and credit notes all work, but Purchase Orders do not change to the translated strings.

This makes me believe there is a bug somewhere that is casusing the strings for the PO to be drawn from doctext2.inc. This would explain why editing the doctext.inc file had no impact on the PO last night until I copied it to overwrite the doctext2.inc file.

Anyway too late here. Let me know what you find.

Re: Australian Translation - Purchase Orders not translated

null@example.com (joe) — Tue, 02 Mar 2010 12:16:49 +0000

Hello rodw.
The strings in doctext.inc should all be surrounded by _("your text").
This is so called gettextizised strings. When poedit extract all the strings for translation it picks up all these texts.

The reason for doctext.inc to have these surroundings is that then it can be used for all translated installations for domestic customer (those with the same currency as the domestic.
The strings in doctext2.inc are NOT surronded by _(""). Therefore these strings is taken as they are.
If you use the same doctext.inc and doctext2.inc, then please backup doctext2.inc. This file will be overwritten when upgrading. After upgrading you will have to restore this file again from your own.

/Joe
BTW. Happy translating

Australian Translation - Purchase Orders not translated

null@example.com (rodw) — Tue, 02 Mar 2010 12:08:38 +0000

Hi Guys

Seeing Joe asked nicely on another thread , I have had a try at creating a translation file for Australia.

So far, everything seems to be fine except that Purchase Orders have not been translated so the PDF files still show all the default UK VAT stuff instead of or GST.

I see a another report of this issue on this forum. Why is this so?

Something just dawned on me. Last night I did some customising of the reports by playing with doctext.inc and doctext2.inc and I was only testing it against the purchase orders. I initially made my changes to doctext.inc but nothing changed in the PO until I copied the file to doctext2.inc. I suspect therefore that the PO is drawing its strings from this file not doctext.inc and therefore is not getting caught by the .PO language file.

I am not quite ready to share this yet but for one evening's work it is pretty good for a first cut if this problem can be resolved.