Jump to content

dragan

Members
  • Posts

    2,007
  • Joined

  • Last visited

  • Days Won

    21

Posts posted by dragan

  1. Thanks!

    But sadly, this doesn't work (no error messages either). I put this in the site root - I'm probably missing something?

    // Bootstrap ProcessWire
    include('./index.php');
    
    // Assign API variables
    $fields = wire("fields");
    $templates = wire("templates");
    $languages = wire("languages");
    
    $en = $languages->get('en');
    $us = $languages->get('us');
    $fr = $languages->get('fr');
    
    $field = $fields->get('prod_max_power_consumption');
    
    $field->set("label$en", "Max. Power Consumption TEST");
    $field->set("label$us", "Max. Power Consumption TEST");
    $field->set("label$fr", "Max. consommation de courant TEST");
    
  2. Thanks Ryan.

    It works - but if I add the following code to actually output the data, I only get the default language output. If I switch to another language, it still only shows the default language. (PW 2.3.2, all field labels and values are correctly and fully translated)

    foreach($children as $f) {
        $fieldName = $f->label;
        $fieldValue = $page->$f;
    
        if(strlen($fieldValue) > 0) {
            echo "<dt>$fieldName</dt>\n";
            echo "<dd>$fieldValue</dd>\n";
        }
    }
    

    Do I manually have to add something to make this language-aware? Something with $user->language or such? I was under the impression that wouldn't be necessary anymore with the dev version 2.3.2.

  3. I've posted a question in another forum thread, because I initially didn't want to create a new forum thread for this. Since there were no replies, I'm trying it here.

    I'd like to set input field labels for each language via API. I have approx. 50 input fields and four languages. Doing it "manually", i.e. via GUI, would take ages, as you can imagine.

    Is there an API method I can use? a) get/define field, b) set language-specific field label

    To clarify: This is not meant to run inside a template, but just once, i.e.

    // Bootstrap ProcessWire
    include('./index.php');
    
    // Assign API variables to make things a little easier
    $fields = wire("fields");
    $templates = wire("templates");
    

    etc.

  4. Nobody has any idea? I wasn't sure if I should rather post this question in one of the multilang forum threads, open a new one, or post here. (and I sure hate to cross-post)

    I'll be probably soon receiving a massive MS-Excel list of data that has to be exported to PW via API. The data won't be in the default language, so I'd really be eager to know how this can be accomplished via API (if at all - but knowing PW, I guess it's definitely just 2-3 lines of code...).

  5. Edit: durr... I forgot fieldset tabs!  :rolleyes:

    http://processwire.com/talk/topic/1592-problem-with-fieldset/

    Feel free to delete this post / thread altogether...

    =====================================================================

    Is there a method or module to group a certain number of input fields in a template (backend, edit mode)?

    I have basically two input field categories - product features and product description. Both categories have 1-2 dozen input fields. Together with all the other fields, it can get messy in the backend, even if I reduce the input field width to 25%. Is there a way to

    a) move a bunch of input fields to dedicated tabs?

    or

    b) include those in a collapsible group that are closed by default?

    I thought that field groups were the tool to use for this, but I'm not sure if or how.

    • Like 2
  6. I've used API code to create a whole bunch of TextLanguage input fields, with the example @ http://processwire.com/talk/topic/1051-adding-and-assigning-fields-without-using-gui/?p=36795

    Worked like a charm. Now my question: Is it possible to also assign distinct labels for each language via API? (I have a multilang site, using 2.3.2 and MultiLangPageNames)

    Should I use somehow wire('user')->language and switch for each lang. in my script?

    Or can I add a parameter directly to $f->label = "foo"?

  7. I used to run into strange issues too - also with other systems when transferring files one-by-one. Nowadays I zip locally and transfer the zip and unzip it on the server. This way I can be sure all the rights, files, et cetera will be transferred.

    Yep, I do it like that too. It's also a lot faster than transferring files one-by-one. On the server, it unzips in 2-3 seconds. Most hosting control panels have such a feature in a file-manager tool.

    • Like 1
  8. I agree about the pictures being over-saturated. This might be OK for an Instagram audience, but on a "regular" website, it's a bit over-the-top.

    Also, the wooden design elements are a bit too much in some places, e.g. the Europe map http://www.johannsmann-pferdetransporte.de/en/contact/

    In the german-language contact form, I'd change the date input format to DE standard tt.mm.jjjj instead of dd/mm/jjjj.

    Likewise, change the TT/MM/JJJJ in the english version to dd/mm/yyyy. (it's day, not tay, and year, not jear...)

    Here and there, you can still spot some typos, like "Other assests" :-)

    Apart from these details / nitpickings, a nice site, with a consistent look + feel.

    Out of curiosity: Which PW-version did you use? I'm asking because of major differences how you can handle multilingual sites (2.3.0 stable vs. dev version 2.3.2).

  9. Wow, you guys are truly great. Thanks for your patience. It's all solved now. I can't believe how easy it all is now. I was basically starting with an older technique, switched to the new one, and there was still all kinds of legacy code here and there. Strange redirects, 404s etc.

    Remember that I owe you a beer if you should ever come to this neck of the woods...  ^-^

    • Like 1
  10. Thanks again for the heads-up. I thought I had removed / disabled all old modules that were in place when I started out.

    I definitely do want to use the newer method with LanguageSupportPageNames. Guess I have to play Sherlock Holmes now and take another look if there's anything left that interferes with the latest LSPN method.

    Question then: With LanguageSupportPageNames, is it still necessary to enable URL-segments for each template? Or is that also obsolete now? Perhaps that's causing all the issues I'm encountering? (we don't have any pagination, so that's no issue)

  11. Well, here, it does show correct page-titles, but it omits the last URL-segment, and so it always jumps back to the default URL :-| 

    btw: I installed a fresh new 2.3.2 with MSN module, and it does the same.

    languages are setup, all text-fields are multilang, all templates have URL-segments enabled, and in the header there's something like

    if($input->urlSegment1 == 'de') $user->language = $languages->get('de');
    if($input->urlSegment1 == 'fr') $user->language = $languages->get('fr');
    
    if(!$input->urlSegment1) $user->language = $languages->get('default'); // english
    
  12. How difficult would it be to create a module version that supports the new 2.3.2 multilang features?

    i.e. if I use the Language Support Page Names module, Lang-Fields + URL-segments.

    exactly as described here: http://processwire.com/api/multi-language-support/multi-language-urls/

    Creating mulitlang-links with the API is now a breeze:

    $userLang = '';
    if(!$user->language->isDefault()) $userLang = $user->language->name;
    $myURL = $pages->get(foo)->url . $userLang; // append language code
    

    Would I simply have to change something here ? (lines 267 of your module): 

    // if page object from a page field get its url
    else if($f instanceof Page){
        $field_value = $f->url;
    

    Maybe adding an optional parameter like "multilangAware"?

×
×
  • Create New...