$sectionRelativeCode in Edit.php

[mahotilo]

I try to connect file with translations to Edit.php and I see that $sectionRelativeCode is not defined hear. So I can't correctly call file_exists() to check my lang-**.php. Can we have $sectionRelativeCode in Edit.php also?

P.S. I18n is a pain:)

[juek]

You could include you language file in editor.php like that

global $config;
$language = $config['language'];
$lang_file = $addonPathCode . '/_types/' . $type . '/i18n/' . $language . '.php';
if( file_exists($lang_file) ){
  include $lang_file;
}else{
  // default language fallback
  include $addonPathCode . '/_types/' . $type . '/i18n/en.php';
}

[mahotilo]

Thank you a lot

$type was a keystone for me

[juek]

Just added a native i18n implementation. See this commit

It's not mandatory. Of course you can still always use a custom implemetation.

See the new Section Type multi_lang_demo

[mahotilo]

Cool. Native i18n. But if someone forget to translate some string we will get empty string. May be we need to load at first some default.php with native section strings? Then in case of missed translation we will have a default value, not ''. What is default? I don't know:) May be add variable var $default_lang_code = en?

So, as yet I stay with my own rough i18n code in my first section type :) But next type will use native i18n support.

P.S. Custom sections... It is rather Section designer? Section RAD? Section framework? :)

[juek]

But if someone forget to translate some string we will get empty string. May be we need to load at first some default.php with native section strings?

Maybe. But for custom section types I think we would start with one language and then add others by copying the file. So if the translation of a term is unknown, we would probably simply keep the original language one (or rather goggle it ;-)

[mahotilo]

Of course. It is scenario for forked and still in developing plugin. If owner adds new strings old translation file will cause a problem in "updated" fork. And I always forget to synchronize my own translations:)

[mahotilo]

I trying to add translation to universal_editor\editor.js

852: multi_img_ctl += '<button id="editor-btn-multi-img-'+ item +'"><i class="fa fa-image"></i> '+self::$i18n['editor']['langmessage']['Images']+'</button>';

But I get an error. Is self::$i18n['editor']['langmessage'] not allowed there? Or I doing something wrong?

[mahotilo]

Oh, Juergen Something goes wrong. In admin mode CustomSections work fine, but not in user mode. I have checked it on clear TS with Shop_item too. Same result. No carousel, no, title, no description...

[juek]

Any Custom Section must be (edited +) saved once to work (unless it has $always_process_values = true, which is only needed to process dynamic data like dates and false by default in shop_item). And don't forget to also publish the page.

We could actually try to force an initial save right after a Custom Section is inserted but not yet edited. Hmm...

[juek]

Did you edit and save the section once?

[mahotilo]

Yes, saved and published. Can you reproduce this error with single Shop_item? Maybe it is due my server and intensive editing with many errors?

[juek]

Can you reproduce this error with single Shop_item?

I'll try...

[juek]

I can reproduce it. But once I edit the section and e.g. change the availability value, after saving and publishing its fine.

[mahotilo]

Yes, now I see this too. I got into that trap due my testing of sections without its editing. In real world it should not happened.

Is it intentional? It scare users:)

Thank you for help!

[juek]

When you open http://www.test:8080/Admin/Errors are there any remaining erros?

[mahotilo]

No.

Hooray! No fatal errors found

[juek]

Is it intentional? It scare users:)

Well, no, not exactly intentional. In production, we wouldn't use unedited sections normally. But I agree, it is scary. I'll try to fix it.

[juek]

Got it.

[mahotilo]

Thx! Works like a Swiss watch. No, in this case Swiss Knife.

[juek]

Late reply to

What is default? I don't know:) May be add variable var $default_lang_code = en?

Default is Typesetter's admin UI language (via configuration) but i18n will fall back to 'en' if the default language definition doesn't exist. If no i18n exist at all, the array is simply empty.

From my point of view, Custom Sections is (at least for now) not a general-purpose addon but rather a tool to generate project-specific output. Therefore I assume that any custom section will primarily meet the demands of a distinct website. So the devloper will care about everything including required translations.

Of course, we may create versatile custom section types to be used in different projects, extend them and even add a wide set of translations. In practice, sharing them would need additional infrastructure, namely an internal package manager able to manage downloads/installation/versioning and conflict management. Building such would be a lot of work, therefore I would rather go for including CustomSections into the Typesetter Core and deliver custom section types as 'regular' Typesetter Addons. But we're far apart from that and IMO the community is too small that it would make sense.

[mahotilo]

...and IMO the community is too small that it would make sense. Yes, I think TS is terrible undervalued.