Rainer Lang
Forum Replies Created
-
Posts
-
Hi Kiran,
thank you. I’ve updated it now, but the issues are still the same.
(It would be helpful if you offer a date or version number when a new update is available in Stiofans post.)
This reply has been marked as private.Now I read this in the item specific settings:
“When you select physical product rules, only consumers and businesses in your country will be charged VAT. The VAT rate used will be the rate in your country.
If you select Digital product rules, VAT will be charged at the rate that applies in the country of the consumer. Only businesses in your country will be charged VAT.”We tried both: physical and digital product, but both are calculated without tax in checkout cart.
But anyway in our Country (Germany) we need to apply taxes on digital products to private customers, too.Hello,
some feedback for the checkout:- We have only “Pre bank transfer” activated as payment method. The checkout page displays in section “Selevt Payment Method”: “No payment gateway active”. It should show the pre bank transfer description instead.
- By default, tax is not applied. You first have to enter Company name and VAT number. Tax should always be applied by default. In our case we don’t want the VAT check at all. All customers should pay the prices including tax.
Suggestion: settings option if VAT check should be used, if not completely remove tax details section from checkout
yes filters would be fine
Hi Stiofan,
thanks for your reply! Sorry for maybe wrong accusing. (We got that feeling afer the security issues, but that’s another topic.)
Yes, my solution would only work for places and events, that’s right. For other CPTs it would stay as it is.
I think your idea would not add this to the po files. I’m not sure about your mentioned functionality. But when I tried it before, the db-language.php stayed empty, no strings added to po or anywhere.I now installed your custom post types addon to get an idea of it. I didn’t start using it yet, but if it works as expected it could be an idea to add the mentioned strings to the LABELS in advanced mode. (“Place Title” and “Place Description” to the label section of advanced edit mode of post type gd_place, and “Event Title” and “Event Description” to the label section of advanced edit mode of post type gd_event).
What do you think about that?After backing up my testing environment and setting up the custom post types to our use, I’ll let you know.
We’d like to test this plugin, too. Is the new beta out already?
(The first invoicing-1.zip cannot be downloaded anymore – 502 Bad Gateway)and @guust you are wrong: Of course we already translated “Place” and “Event” in the language files. But the problem is, that in these code pieces mentioned by me, the translation is not used!
We already setup everythin with places ant events. Now you want us to completely start new with custom post types? Only because you don’t want to change these two code pieces?So, since I had to repeat this, I repeat my suggestion for a patch, too:
As the two main posttypes are places and events, I’d suggest to add a conditional clause:
in geodirectory_template_actions.php this is line 2215:<label><?php echo sprintf( __('%s Title', 'geodirectory'), $cpt_singular_name ); ?><span>*</span> </label>change it to:
<label><?php if($cpt_singular_name == 'gd_place') _e('Place Title', 'geodirectory'); elseif($cpt_singular_name == 'gd_event') _e('Event Title', 'geodirectory'); else echo sprintf( __('%s Title', 'geodirectory'), $cpt_singular_name ); ?><span>*</span> </label>the same for description would be in line 2267:
<label><?php echo sprintf( __('%s Description', 'geodirectory'), $cpt_singular_name ); ?><span><?php if ($desc_limit != '0') { echo '*'; } ?></span> </label>change it to:
<label><?php if($cpt_singular_name == 'gd_place') _e('Place Description', 'geodirectory'); elseif($cpt_singular_name == 'gd_event') _e('Event Description', 'geodirectory'); else echo sprintf( __('%s Description', 'geodirectory'), $cpt_singular_name ); ?><span><?php if ($desc_limit != '0') { echo '*'; } ?></span> </label>So if I have to translate “%s Title” with your type of logic, this would be:
“Place Title” = “Titel Platz” (completely wrong German) or “Titel der Platz” (completely wrong, too)
or I set this to “Titel des Platzes” – nice, this would be right, BUT (!!!) then “Event Title” would be “Titel des Veranstaltunges” (uaaah, completely wrong!)
Got it??again, the problematic is about the following:
“%s Title” and “%s Description”In German the correct translation for “%s Title” would be:
“Place Title” = “Titel des Platzes”
“Event Title” = “Titel der Veranstaltung”Do you see the difference?
The genitive declination of “place” is in German with the pronoun “des” (and this is different from “der” – can you read?), and ends on “es”, the German word for event is “Veranstaltung” und doesn’t have a genitive ending.Is that so hard to understand?
your way to translate individual post type names, mentioned in the topic linked above, doesn’t help us at all. We don’t use custom post types, we use places and events only.
So, I tried using GD Tools as described, but the file db-language.php is empty, there is no string added.Hi Paolo, sounds like this will take still a while… is there a Kind of handbook describing the current functionality of the payment Manager. Today I do not really know what I can do with all the field Settings, e.g. in a Price package.
Using custom post types addon maybe a solution just for renaming, but why use another addon if we just need translation in our language?
The language strings “%s Title” and “%s Description” are really bad i18n practices. For your better understanding:We use the two post types places and events.
Translation in German:
“Place” = “Platz”, with article: “Der Platz”
“Event” = “Veranstaltung”, with article: “Die Veranstaltung”The correct translation would be:
“Place Title” = “Titel des Platzes”
“Event Title” = “Titel der Veranstaltung”You see?
Thanks, that solves it.
