Titanium JIRA Archive
Alloy (ALOY)

[ALOY-781] Add option to extract-i18n to remove strings not used in code

GitHub Issuen/a
ResolutionWon't Fix
Resolution Date2013-10-02T18:08:02.000+0000
Affected Version/sn/a
Fix Version/sn/a
Labelsalloy, extraction, i18n
ReporterFokke Zandbergen
AssigneeTony Lukasavage


I would to have an option for alloy extract-i18n to remove strings that can not be found in the project's JS, TSS and XML files. Of course this requires TC-2732 to be resolved because ATM, extract-i18n does not account for XML files and textid-like properties. I will attach a PR for this.


  1. Fokke Zandbergen 2013-08-12

    PR: https://github.com/appcelerator/alloy/pull/218
  2. Tony Lukasavage 2013-08-12

    Can you better define what "unused" strings are?
  3. Tony Lukasavage 2013-08-12

    This seems a little dangerous from my perspective and likely to be misused with bad results. The reason I've allowed extract-i18n in as it is with regex search instead of full AST parsing is that its changes are non-invasive. The changes are additive. That's not to say that we can't do it, I just think the interface will need to be more explicit. Makes me wonder if the command should be structured differently, with subcommands:
    alloy i18n extract ...
    instead of
    alloy extract-i18n ...
    and then add
    alloy i18n clean ...
    so that the very different behavior is more explicit. Not sure, but I do know that if this command gets into the business of actually removing entries, then I don't want it to be regex driven anymore and it should fully parse the JS/TSS into an AST and manipulate that way. The views would naturally be parsed as XML and evaluated in a similar fashion.
  4. Fokke Zandbergen 2013-08-13

    Well I don't actually remove the strings, just wrap them in comments. But I do agree that an extract command also removing stuff might be unexpected behavior. We could do:
       alloy i18n extract
       alloy i18n clean
       alloy i18n sync // = extract + clean
    I also agree that proper AST and XML parsing is justifiable, also taking ALOY-782 into consideration (which is required for this issue anyway).
  5. Tony Lukasavage 2013-10-02

    After discussion with Fokke, this ticket will be closed. Further effort here may be made in the next major version of Alloy, but that will likely be covered in entirely separate issues.

JSON Source