Child pages
  • Automate language pack export for deployment script
Skip to end of metadata
Go to start of metadata

Imported From: http://groups.google.com/group/in-portal-dev/browse_thread/thread/4a5d374dae59bfbd#

Deployment script is a real time saver when it comes to deploying an update to dev/live servers.

However it still requires user actions in terms of exporting latest language pack and comparing it to one we have right now.

Right now I'm doing this (see below) to export language pack for each task:

  1. click on "Regional" section in Admin Console
  2. select English language
  3. click on Export toolbar button
  4. enter language pack filename
  5. click on "Select None" to uncheck all modules
  6. click on "Custom" to select module which I want to export
  7. click on Export button on toolbar

These are horrible 7 clicks I need to make just to have "Custom" module's language pack being exported.

I'm proposing to perform an export of all language packs from modules, that have "project_upgrades.sql" file when "Synchronize" button is pressed in "System Tools" section.

As a result we'll have a separate language pack for every module, that is used by deployment script.

Related Tasks

INP-1197 - Getting issue details... STATUS

6 Comments

  1. As of part 2 of my post I'm proposing to add "SSHCommand" setting to system
    settings or to /system/config.php

    Then in deployment script we can use this setting to execute commands on
    Host OS (e.g. Windows/Mac) from Guest OS (e.g. Linux) installed on Virtual
    Machine, where In-Portal is installed.

    If you're using Windows as your Host OS, then it you need to install SSH
    server separately.

    However if anybody can find a way to run commands from Guest OS on Host OS
    via VMWare tools or something, then please let me know.

  2. Here is the patch and task:

    INP-1197 - Getting issue details... STATUS


    Ready for testing.

  3. Hi Alex,

    I am not sure I fully understand why Host OS is evolved here. Can you
    please explain in full details how it works?

    The way I see it:

    1. we add new phrases to DB where In-Portal is installed (Guest OS) by
    adding phrases via Admin or so
    2. then we can automatically-dump/export the DB into language pack
    (english.lang) for each module (once you click Synchronize or we can have
    new button if needed) - ie. for custom module only
    3. then it's Committed as part of all changed files in the task and
    Deployed to everyone else.

    DA

  4. *I am not sure I fully understand why Host OS is evolved here. Can you
    please explain in full details how it works?*
    *
    *
    Because tool, to compare changes made in new language pack
    (/system/export/Custom.lang) and old language pack
    (/modules/custom/install/english.lang) is located in Host OS. I'm too lasy
    to click multiple buttons, that's why I made ONE button to do both:

       - language pack export for every module featuring in deployment script
       - compare tool invoking that would as result update module's language
       pack file, that will be commited later

    *
    *
    *The way I see it:*
    *
    *
    *1. we add new phrases to DB where In-Portal is installed (Guest OS) by
    adding phrases via Admin or so*
    *2. then we can automatically-dump/export the DB into language pack
    (english.lang) for each module (once you click Synchronize or we can have
    new button if needed) - ie. for custom module only*
    *3. then it's Committed as part of all changed files in the task and
    Deployed to everyone else.*

    Between 2 and 3 you actually compare exported language pack to one you have
    and add/remove phrase changes made by you. I can't automate that part.

  5. Thank for reply Alex.

    I still not clear why either of these two options don't work for us:

    1. You can use DIFF too on GuestOS and compare 2 files (current and
    temporarily) or something like we do with Admin CSS on upgrade

    2. Do we really need to compare anything - consider when Synchronize is
    pressed we Save all changes (overwrite current) from DB (all new and/or
    changed phrases) to /modules/custom/install/english.lang on Guest OS since
    it's setting there (an will be committed from there).

    DA

  6. *1. You can use DIFF too on GuestOS and compare 2 files (current and
    temporarily) or something like we do with Admin CSS on upgrade*
    *
    *
    Since this task is performed several times per day by each developer I
    seriously doubt that you want to work with b/w diff form command line (on
    guest os) comparing to nice looking GUI tool (on host os).

    *2. Do we really need to compare anything - consider when Synchronize is
    pressed we Save all changes (overwrite current) from DB (all new and/or
    changed phrases) to /modules/custom/install/english.lang on Guest OS since
    it's setting there (an will be committed from there).*

    Consider this test case:

       - developer A performed SVN update, but haven't imported language pack
       changes made by developer B
       - developer A adds some phrases
       - developer A clicks on synchronize button and, as you suggest,
       overwrites all changes made by developer B
       - developer A commits his changes even not looking at changes made to
       /modules/custom/install/english.lang file

    I prefer to take precaution and let developer decide what gets overwritten
    and when. Plus /modules/custom/install/english.lang file isn't writable
    from web server.