Child pages
  • Change module selector on language pack export screen to multiselect
Skip to end of metadata
Go to start of metadata

Imported From:

I propose to Change module selector on language pack export screen to multiselect (from checkbox list) because a lot of checkboxes (when you have more then 3 modules installed) are not an easy way to select specific module for exporting.

Related Tasks

INP-380 - Getting issue details... STATUS


  1. I would actually disagree with that. I would rather select all by
    default since in most cases you export all so it's easier to un-check.

    Other thing is we might want to list modules in 1 column and provide
    some additional info like Number of Phrases and Event Events in each
    Module for this Language that will be exported.

    What you think?


  2. You didn't get my point here. What I mean here is that list of checked
    checkboxes is replaced with multiselect where all items also are all
    checked. When user doesn't touch checkboxes, then all works the same. Change
    is that to uncheck element he need to hold "Ctrl" and he will be able to
    select one module just by clicking on it (this will unselect all previously
    selected modules and select given module).

  3. Yes, I do understand your point - we are trying to simplify the

    In particular we need a way to quickly select all and un-select all

    At the same time I believe we should not lose ability to extend by
    adding new features which actually might very useful and informative.

    In my opinion by using single Multi-Select area we'll loose ability to
    list additional information about module Phrases.

    I would approach it this way:

    1. List all modules with Check-boxes in one column
    2. List additional info (number of Phrase and Events) next to each
    3. Provide Select ALL and NONE options above check-boxes.

    Also, I think it makes sense to pass this to out Designs Interfaces

    What you think?

    to unselect User will be doing the same number of clicks + needs to
    hold Ctrl.

  4. I see you've find the solution, that will satisfy both parties. About design
    I think that two links above checkbox list (Select All, Unselect All) is
    what we need, so we won't need to bother designers about that. Also your
    previous idea about texaareas, where user can specify only phrases/email
    events (by name), that need to be exported also looks very useful. All that
    would be a nice feature for 5.1.0 release.

    By the way we should start composing *5.1.0 release* (in issue tracker). I
    think, that 5.1.0 will mostly consist of a lot small features, rather, then
    a small count of large features.

  5. This has been filed as new Feature Request:

    455: Interface Improvements to Language pack Export

    INP-380 - Getting issue details... STATUS

    No version selected just yet, but we'll discuss this shortly.


  6. Here is how it will look (screenshot after patch is applied).

  7. nice design, simple and clear. to export specified phrases or e-mails
    events, should we use their ID or their inportal label? Separated by ?

    last remark: it's a long time I don't make any difference between
    modules lang packs, but rather websites langpack, as when you do mods
    on a website, they are related to the business they run, and for
    example you can do a change to core labels, and this changes could
    reflect the fact we are using only in-commerce, i.e. such changes
    alone won't be of any help for another website.

    Should it be possible to use a full lang pack (with all modules), and
    the system will install only the needed langs, based on installed
    modules? it could keep the raw lang pack for futures modules install
    (or even use the online lang pack update as we've seen in another
    post), avoiding the missing labels when installing new modules, as
    we've seen before, and we would only maintain 1 big lang pack and not
    a myriad of small packs which are raely used alone new they are nearly
    all for free.

    Good night Alex, I go offline :)

    2010/3/22 Alexander Obuhovich <>:

  8. Hi Phil,

    I'll answer your both questions:

    1. You specify the Label or Event Name if you want to export something
    specific and not the Entire Language pack (or module)

    2. You are missing very important point here. As we all know our goal is to
    get lot's of translations these are our main points:

    a. It's very unlikely someone is going to translate 4K+ language pack
    b. It's easier to maintain since we are making modules fully independent
    from In-Portal Core
    c. Front end language pack is fully independent and Module based now too
    since I don't need phrases I have in Onlinestore theme installed for
    Advanced and other way around.

    To answer your question about custom labels that you are adding changing.
    What we do - we add all NEW labels to a Custom module (Dev Kit) which is
    what we always install for all our projects. The main purpose of the Custom
    module is to add new and extend existing PHP functionality (classes)

    By the way, we notice very minor activity in the Localization group - who is
    the Leader down there? ;)



    On Mon, Mar 22, 2010 at 5:15 PM, Phil ..:: ::.. <

  9. Alex - VERY good work as always!

    Exactly what we planned.


  10. Small note here:

    1. there is bug, that prevents hints for these two fields (textarea) to be
    shown, but patch is already up for testing and will be included once
    5.0.3-B1 will be released.
    2. in that hint label there is detailed explanation what data format should
    be used
    3. we are actually combining selected module + entered phrase names +
    entered event names

    If entered event/phrase names should override selected modules from above,
    then please tell my why. For example I can specify some phrases and none
    events and in this case want these phrases + all events exported from
    selected above modules.

  11. Hello Dmitry,

    1. ok

    2. I agree with you, just few remarks:

    a. sure it's a big job, but done only once
    b. as I told you before, I've make coding a perl script which detects
    new tags :)
    c. I agree

    Ok for module "Custom", I'd be happy to read more about it, how it
    works, how we can code things in it...

    About localization group:
    - I've asked by e-mail on 20th march if something else was needed
    about the fact french lang pack is marked as "not complete" on
    - I'm still waiting an answer in
    - I'm on the go to create new lang packs for front-end (in new languages)


    2010/3/23 Alexander Obuhovich <>: