Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#3239 closed defect (fixed)

build: i18n module flattening in build is not working

Reported by: jburke Owned by: jburke
Priority: high Milestone: 1.0
Component: BuildSystem Version: 0.9
Keywords: Cc: pic@…
Blocked by: Blocking:

Description

Specifically, the part that optimizes the dojo.requireLocalization calls to add the list of available locales.

Change History (14)

comment:1 Changed 10 years ago by jburke

  • Resolution set to fixed
  • Status changed from new to closed

(In [8872]) Fixes #3239. Flattened i18n bundles should load correctly after a build.

comment:2 Changed 10 years ago by guest

  • Resolution fixed deleted
  • Status changed from closed to reopened

I believe that this problem is still present for bundles in external modules. I've debugged a bit the code of the build system and it seems that, in i18nUtil.js, _moduleHasPrefix("ext_mod") returns false, though ext_mod prefix is declared in profile file.

comment:3 Changed 10 years ago by guest

contact: pic at superfluo.org

comment:4 follow-up: Changed 10 years ago by jburke

  • Milestone changed from 0.9beta to 1.0

Can you provide a sample build profile file? I've tried with other prefixes, but those build prefixes pulled in dojo or dijit i18n bundles. Also, it would be good to know if the ext_mod modules reference i18n bundles inside of the ext_mod directory structure.

comment:5 in reply to: ↑ 4 Changed 10 years ago by guest

Can you provide a sample build profile file?

it's elementary:

dependencies = {
  layers: [
    {
      name: "pcpg.js",
      dependencies: [
       "pg.main"
      ]
    }
  ],
  prefixes: [
   ["dijit", "../dijit" ],
   ["dojox", "../dojox" ],
   ["pc", "../../pc"],
   ["pg", "../../pg"]
  ]
} 

pg is the ext_mod of my previous comment.

Also, it would be good to know if the ext_mod modules reference i18n bundles inside of the ext_mod directory structure.

yes, the bundles are in pg/nls/messages.js and pg/nls/it/messages.js, and are required with:

	dojo.requireLocalization('pg', 'messages');
	this.messages = dojo.i18n.getLocalization('pg', 'messages');

btw, outside a built release everything is fine.

PS: please add my email (pic at superfluo.org) to CC of this ticket, thanks

comment:6 follow-up: Changed 10 years ago by jburke

  • Cc pic@… added

Thank you for the info. Using a test similar to your build file did not seem to show any problems. The layer file gets generated with the dojo.i18n._preloadLocalizations() call at the end of the layer, and the dojo.requireLocalization call in the layer has been removed. The corresponding flattened i18n bundle also seems to exist.

I cannot find a reference to _moduleHasPrefix in i18nUtil.js. Did you mean i18n.js?

Are you running the 0.9.0beta? If so, the 0.9.0 has been released this week. I just want to be sure we're running the same code. If you are using the code from the subversion trunk, you might try with r10343. I did fix an issue with nested layer files (issue #4246).

What is the build command you are running?

So are you seeing this issue at runtime? If so, how are you loading pcpg.js? What is the behavior that indicates to you there is a problem?

comment:7 in reply to: ↑ 6 Changed 10 years ago by guest

I cannot find a reference to _moduleHasPrefix in i18nUtil.js. Did you mean i18n.js?

no, sorry, I mean dojo/_base/loader/loader.js

I believe in fact that my problem begins in the eval in i18nUtil.js, line 61. There, dojo.requireLocalization('pg', messages) is evaled in the context of dojo source (../../dojo respect to buildscript path) and ignoring the prefixes given in the profile file. So, the bundle is searched with ../pg/nls/messages.js (because _moduleHasPrefix doesn't find any registered prefix for pg) instead of ../../pg/nls/messages.js and, of course, isn't found.

In this way, the namespace pg.nls.messages has properties ROOT, it and xx but they are all undefined and an exception is throw later, in i18nUtil.js, line 220.

I just want to be sure we're running the same code.

I'm running the HEAD of the trunk

What is the build command you are running?

buildscripts$ java -jar lib/custom_rhino.jar build.js 
profileFile=../../../../../config/dojo-0.9/pcpg.profile.js 
action=clean,release localeList=it

So are you seeing this issue at runtime? If so, how are you loading pcpg.js? What is the behavior that indicates to you there is a problem?

prior to [10325] the build terminates successfully but runtime it could not load the bundles, after [10325] the build aborts with the exception described above.

Thanks for your help.

comment:8 Changed 10 years ago by jburke

  • Resolution set to fixed
  • Status changed from reopened to closed

(In [10499]) Fixes #3239. i18n bundle flattening was failing when the module prefixes were outside of the dojo directory (things like dijit and dojox were fine, but for directories that were not a sibling to dojo failed).

comment:9 follow-up: Changed 10 years ago by jburke

I believe i just fixed the issue. Give the latest trunk code a spin if you want to try it out.

comment:10 in reply to: ↑ 9 Changed 10 years ago by guest

Replying to jburke:

I believe i just fixed the issue. Give the latest trunk code a spin if you want to try it out.

yes, thanks! Now I can successfully build the release.

Runtime I have to explicitely load the generated bundles, for example:

<script src="/dojo-0.9/release/dojo/dojo/nls/pcpg_ROOT.js" type="text/javascript"></script>
<script src="/dojo-0.9/release/dojo/dojo/nls/pcpg_it.js" type="text/javascript"></script>

I wonder if there is a best practice to do this, in particular I'd like to load only the bundles required by the current locale.

comment:11 Changed 10 years ago by jburke

You should not need to explicitly load the locales. It should just happen automatically as part of the build. Be sure to specify the locales you wanted optimized by specifying the "localeList" build option (type util/buildscripts/build.sh to see the format for it). it-it is in the default list, you probably want to add just "it" if you are just specifying that locale.

comment:12 Changed 10 years ago by guest

ok, everything is fine now, thanks again.

For the record: my problem was that I was calling dojo.requireLocalization in a module included in the build. Since the build system adds the call to _preloadLocalizations at the end of the build, that causes some troubles. So I had to refactor my code in order to call dojo.requireLocalization exclusively after the inclusion of build file.

By the way, couldn't be useful to anticipate in the build file the call to _preloadLocalizations?

comment:13 Changed 10 years ago by jburke

I'm not sure I follow the failure situation you describe above. A dojo.requireLocalization() call by itself is harmless normally (and for a build that actually tells the build system that a _preloadLocalizations() call needs to be made at the end of a layer build.

An issue I can see if you try to call dojo.i18n.getLocalization() right after a dojo.requireLocalization() call, and you are doing an xdomain build. In that case, the getLocalization() call should be done in a widget lifecycle function or in a dojo.addOnLoad() callback.

comment:14 Changed 10 years ago by guest

of course you are right, the problem was with a call to dojo.i18n.getLocalization() right after a dojo.requireLocalization() but I'm not using an xdomain build but a classic build. The problem consists in an Error thrown because the bundle isn't found.

Anyway, as said, refactoring the code in order to call dojo.i18n.getLocalization() after the inclusion of build file (for example in widget lifecycle, as you suggest) solves the issue.

Note: See TracTickets for help on using tickets.