rfc: updated file-structure for multi-locale .lg and .lu authoring #1922
Conversation
cwhitten
changed the title
|
A few thoughts:
|
|
I'm a bit lost on what we actually intend to do. Based on this,
I believe we are going to keep the related .lu, .lg files in the same location as the .dialog. Yes? Experientially, we need to continue to push the concept of a file away from the user and hoist and provide a seamless, contextual authoring experience for the user. ResourceExplorer and typeloader does not really care about file location but will continue to use fileName or combination of fileName and locale directly encoded as part of fileName to find and load the right resource. |
|
@vishwacsena the experience is out of scope of the doc, this is more of an infrastructure proposal that we can align on and defend. I am proposing we keep the existing convention and keep language files associated with the dialog file. The experience will continue to abstract the file metaphor away. |
docs/rfcs/multi_locale.md
Outdated
|
|
||
| #####Note | ||
|
|
||
| 1. This proposal only applies to a filesystem-based storage plugin, and has little bearing on a database-backed store plugin implementation. **It may have merit to choose a structure that better aligns with a database-driven index approach.** |
There was a problem hiding this comment.
It's totally OK to me that Composer only have a fs-based abstraction layer for storage, and let any other backend storage implement a few fs primitives.
Similar to the idea of Unix\Linux\Plan9, everything is a file. Anyhow, i feel this is a very widely adopted approach to abstract storage and i feel no necessary to seek for a more generic storage abstraction than fs.
| Main.de.lu | ||
| ``` | ||
|
|
||
| ``` |
There was a problem hiding this comment.
I actually like this alternative more, because the workflow i knew is that users tend to group assets by locale (VA is an example).
If our folder structure is like this
/Dialogs
/LanguageGeneration
/en-us
I can image that the effort of adding a new language fr-fr would be as simple as copying the en-us folder into a fr-fr folder and do the editing in place.
In my opinion, this will also help team collaboration because it separate the concern of conversation designers and content write, and even model trainers.
There was a problem hiding this comment.
I wouldn't over-index on a physical layout of the files to align well with collaboration scenarios, though it was mentioned in the preface of the RFC and should be considered to an extent. Abstraction of the file metaphor will need to exist regardless to provide an appropriate experience for content writers.
That said, partitioning on dialog/lu/lg is a valid alternative, but I'd like to discuss a bit more. I agree that in a content editing scenario there is an advantage to physically laying out the files this way. From a dialog "clone" or sharing/publishing to some central location for re-use, physically laying out the dialog/lu/lg in a way that encapsulates the dialog's dependencies would have the advantage.
Additionally, I'd like to propose we hoist the main.dialog to the root of the bot. I see the following layouts as reasonable adjustment.
- main.dialog at root to signify entry-point, partitioned on dialog
/coolbot
main.dialog
/language-generation
/en-us
common.en-us.lg
main.en-us.dialog
/language-understanding
main.en-us.lu
/dialogs
/foo
foo.dialog
/language-generation
/en-us
foo.en-us.dialog
/language-understanding
foo.en-us.lu
- main.dialog inside /dialogs with the rest of the dialogs, partitioned on asset-type
/coolbot
/dialogs
main.dialog
foo.dialog
bar.dialog
baz.dialog
/language-generation
/en-us
common.en-us.lg
main.en-us.lg
foo.en-us.lg
bar.en-us.lg
baz.en-us.lg
/language-understanding
/en-us
main.en-us.lu
foo.en-us.lu
bar.en-us.lu
baz.en-us.lu
While #2 looks clean physically, I tend to prefer the encapsulation and recursive nature of #1 and sets us up nicely to move/share dialogs between bots in the future.
There was a problem hiding this comment.
I've updated the RFC to reflect this.
There was a problem hiding this comment.
#2 do looks clean physically, it would be even more cleaner if we cover the "settings" folder and "schemas" folder.
#1 is recursively and do reflective the dialog structure in certain way, and is better than #2 on certain scenarios like sharing. But my biggest concern of a recursive presentation is that this enforce a tree structure but the dialog structure is actually a graph, that said, if two dialog A, B are both referring C, who should be encapsulate C? Maybe symbol-link can help on this, but as AFAIK, symbol-link in Windows is a mess, also this mean our solution is more complex and have more coupled into a very specific fs concept).
From another perspective, I agree that we are not designing physical layout for collaboration, but i would argue that we probably should not result in a structure that somehow restricting or limiting collaboration on physical files.
A recursive structure, in my opinion, is very easy to go wrong if people ever touch the files themselves and not knowing what's wrong. And it's also hard to reason over the structure, let's say, figure out how many language models are been used. If we don't want users to touch or reason over physical files manually, then why should we align the physical files recursively, why not a layout more friendly for both Composer and user with other tools? What do you guys think @vishwacsena @benbrown @christopheranderson
There was a problem hiding this comment.
It's easy to jump into the mental gymnastics of what are full-blown package manager and dependency resolution challenges, like tree/graph and local module linking, etc. My hope is we can table that discussion but keep it in mind when we make a decision here. But this is my answer to your question:
then why should we align the physical files recursively, why not a layout more friendly for both Composer and user with other tools?
While #1 physically is more nested it is still sensible to reason about and edit with some education and clarity. Can you expand more on how #1 restricts & limits collaboration scenarios? I don't immediately see that.
#2 feels limiting and I'm concerned it suits a point in time (now) that won't work in the future. What if a dialog/sub-tree of dialogs want their own settings file? What if a dialog/sub-tree of dialogs want their own schema definition? We're not nearly as boxed in with #1.
There was a problem hiding this comment.
I'm late (or early to the party depending on your perspective.)
The early design decision for ResourceExplorer was to make resource ids unique and location independent. The reasoning for this was that:
a. It mapped to flat storage easier
b. It allows people to organize files in any manner which makes sense to them.
c. it means references to resources are less brittle because they continue to be correct even if you move files around.
That said, having an convention about how Composer represents them or the way that we we decide to have templates organize things seems like a good idea and will end up being something that people copy.
Some questions/comments I have are:
a. I don't get why the making everything lowercase is a good idea. What is driving that? If it's to make it easier to not have mistakes in references we can make case insensitive, but case is super useful for readability.
b. I am definitely biased towards assets being co-located so that LU/Dialog/LG can be worked with in the local, but I also believe there will be "global" shared assets which will be consumed by the things in the local. It feels like we aren't talking about that. For example, a bunch of LG templates defined at the root which are imported into the local LG files.
There was a problem hiding this comment.
but I also believe there will be "global" shared assets which will be consumed by the things in the local. It feels like we aren't talking about that.
What's implied in this thread is the common.<locale-code>.lg convention, which exists in the proposal, and we do this today as well. The local .lg files will have the ability to import from this asset regardless of how Composer lays the files out. We should use a local .lg template that imports the shared asset automatically that users can then extend to their needs.
You bring up a good point that I mention in the RFC - I posit that as soon as it is ready, Composer takes a hard dependency on the JS Adaptive ResourceExplorer in its storage plugin so the asset resolution mechanisms are exactly the same.
There was a problem hiding this comment.
By "limiting or restricting collaration" of #1, my assumption was "people will collaborate, to some extent, on raw files, no matter what UI we provide".
Based on that assumption, my feeling is a recursive structure is a little bit harder to collocate on some scenarios i was imaging like
- When copying and moving the files
- it's a little bit hard for user to quickly know my bot is completely copied for whaterver reason because i can't quickly glance something is missing when it's nested, especially when it's big (Vodafone has thousands dialogs)
- i'm even concern will it easily exceed some path length limitation in windows (256 by default)
- If I want to send my all lg or lu files to a translator or a writer, (i assume it's a very common workflow, because i see many users have a simple version first, then send the language assets to content writer without sending all the dialogs), i can not easily locate all the files. And once i get back a new version of lg files, i couldn't easily get it back into my bot. If it's a flatten structure, i can simply create a folder for that.
- if something is wrong, the path to the errors could be a little less readable
dialogA\dialogs\dialogC\dialogs\dialogsD\language-generation\a.lgthings like this, - if our lg\lu files are referring to each other, will we put relative path like
[import](../../dialogA/LG/b.lg), moving this dialog will cause the reference to break. (Put id and use resourceExplorer to implement a customized importResolver can solve this).
Those are kind of no big deal issue, it's just thinking about some scenario (may not all valid) give me a general feeling that a recursive structure is not friendly on physically copying, moving, manipulating the files. So hope we take this into consideration.
Regarding the flexibility you talked about
#2 feels limiting and I'm concerned it suits a point in time (now) that won't work in the future. What if a dialog/sub-tree of dialogs want their own settings file? What if a dialog/sub-tree of dialogs want their own schema definition? We're not nearly as boxed in with #1.
If we organize the dialog as tree\sub-tree, we definitely gain some extra space to configure\customize on tree\sub-tree, while at the same time, the cost is we organize the dialog as tree.
If it's the last chance we want to make change to folder structure, a structure without flavor perhaps is more likely to last than a structure with more flavor.
And, at the end, anyhow we should pick resourceExplorer in js to identify and load resources, what's missing today in resourceExplorer is creating resource following some pattern\layout, that's a gap Composer need to fill.
There was a problem hiding this comment.
I'm even later than Tom. A few things:
- In the generator we currently put all .lg/.lu files into a single localized directory, i.e. en-us. We also have a single top-level .lg/.lu file in that directory which points to all of the component .lg/.lu files.
- For .dialog files, the assumption seems to be that there is a single .dialog file with all assets inline. In the generated dialogs case we make use of the ability to refer to named dialog files to split out all of the individual trigger dialogs. This makes it much easier to look at each dialog--they all fit on less than a page. Would I still be able to do that?
Part of the reason that I care about breaking things up into smaller files is that there is important information in the structure of the filename which should allow being intelligent about merging regenerated assets. We don't have to have separate files if we support id as a first class thing when defining things inline. An id is either explicitly specified inline or cannot be specified and comes from the filename.
There was a problem hiding this comment.
I like #1 but I have few questions (see below)
Also, I was providing some of my personal experience working on internationalization/ localization to @cwhitten other day. In my prior experience both on Internet Explorer as well as on Cortana, what I have seen is localization is more effective when the person localizing is enabled with three things - a) able to see full context into what's going on rather than mere strings in a text file b) able to readily test their changes c) able to always see what the base language version of the exact same string was (so they are essentially not just overwriting the base language string and then losing context into what the old string was).
So my 2c - we should not try to gate our decision to enable a purely file based localization. Instead just have the localization team use composer and use source control to reject any changes to .dialog files. In fact this was how IE was able to simultaneously ship 60+ languages on the same day as English.
With that said, @cwhitten, few questions for option #1
/coolbot
coolbot.dialog
/language-generation
Can you elaborate a bit on the logic to decide to create a 'lang-locale' sub-folder? In some cases, I see this but in other cases, I see we will directly write out name.lang-locale.ext file directly.
/en-us
common.en-us.lg
Can you help clarify why .dialog file show up under LG in this case?
coolbot.en-us.dialog
/language-understanding
Same as previous comment - unclear on what logic we'd use to decide to have a lang-locale sub-folder
main.en-us.lu
/dialogs
/foo
foo.dialog
/language-generation
/en-us
foo.en-us.dialog
/language-understanding
foo.en-us.lu
|
Another related issue is the in-line vs. out of line representation for .dialog files. In-line leads to big files which might make group editing more difficult since you need to lock regions. Out of line provides finer-grained control. In the generated case we have a root directory where there is a main dialog which points to every event handler dialog file. (Even if we do go inline, it would be useful to provide unique id’s for the inline.) The localized assets are all in the en-us directory with a single .lu/.lg file which points to all of the individual files. This structure means that each individual file is easy to look at, control access to and merge. Eventually composer should be able to look at an organization like this, but the question is what happens when you modify or add to it? If you modify a trigger handler does it move inline? If you add a new one is it defined inline? I would propose this:
1. When you modify something it happens where it is defined. If I modify a trigger handler and it is in a file that is where it gets modified. If I modify an lg template it modifies the file where it is defined.
2. When you add something, the composer should do what it likes. If you add a trigger handler it is fine to define inline if that is the right model. (I still prefer out-of-line, but inline would work.) If you add a new .lg template, it should go in the file that the dialog points to, or its parent dialog. In the generated case, this would be the top-level .lg file that points to all of the other .lg files.
Generated structure:
[A screenshot of a computer screen Description automatically generated]
The overall .lu file sandwich.en-us.lu:
>> Library
[sandwich-number.en-us.lu](../en-us/sandwich-number.en-us.lu)
[sandwich-dimension.en-us.lu](../en-us/sandwich-dimension.en-us.lu)
[sandwich-personName.en-us.lu](../en-us/sandwich-personName.en-us.lu)
[sandwich-money.en-us.lu](../en-us/sandwich-money.en-us.lu)
[sandwich-Confirmation.en-us.lu](../en-us/sandwich-Confirmation.en-us.lu)
[sandwich-PROPERTYName.en-us.lu](../en-us/sandwich-PROPERTYName.en-us.lu)
[sandwich-QuantityEntity.en-us.lu](../en-us/sandwich-QuantityEntity.en-us.lu)
[sandwich-NameEntity.en-us.lu](../en-us/sandwich-NameEntity.en-us.lu)
[sandwich-BreadEntity.en-us.lu](../en-us/sandwich-BreadEntity.en-us.lu)
[sandwich-MeatEntity.en-us.lu](../en-us/sandwich-MeatEntity.en-us.lu)
[sandwich-CheeseEntity.en-us.lu](../en-us/sandwich-CheeseEntity.en-us.lu)
[sandwich-helpIntent.en-us.lu](../en-us/sandwich-helpIntent.en-us.lu)
[sandwich-cancelIntent.en-us.lu](../en-us/sandwich-cancelIntent.en-us.lu)
[sandwich-noneIntent.en-us.lu](../en-us/sandwich-noneIntent.en-us.lu)
[sandwich-sandwich.lu](../en-us/sandwich-sandwich.lu)
[sandwich-readPropertyIntent.en-us.lu](../en-us/sandwich-readPropertyIntent.en-us.lu)
The overall .lg file sandwich.en-us.lg
>> Library
[sandwich-Confirmation.lg](sandwich-Confirmation.lg)
[sandwich-PROPERTYName.lg](sandwich-PROPERTYName.lg)
[sandwich-QuantityEntity.lg](sandwich-QuantityEntity.lg)
[sandwich-common.lg](sandwich-common.lg)
[sandwich-Quantity.lg](sandwich-Quantity.lg)
[sandwich-Length.lg](sandwich-Length.lg)
[sandwich-NameEntity.lg](sandwich-NameEntity.lg)
[sandwich-Name.lg](sandwich-Name.lg)
[sandwich-BreadEntity.lg](sandwich-BreadEntity.lg)
[sandwich-Bread.lg](sandwich-Bread.lg)
[sandwich-MeatEntity.lg](sandwich-MeatEntity.lg)
[sandwich-Meat.lg](sandwich-Meat.lg)
[sandwich-CheeseEntity.lg](sandwich-CheeseEntity.lg)
[sandwich-Cheese.lg](sandwich-Cheese.lg)
[sandwich-Price.lg](sandwich-Price.lg)
Trigger handler dialog files:
[A close up of a logo Description automatically generated]
And the overall sandwich.main.dialog:
{
"$schema": "https://raw.githubusercontent.com/microsoft/botbuilder-dotnet/master/schemas/sdk.schema",
"$kind": "Microsoft.AdaptiveDialog",
"recognizer": "sandwich.lu",
"generator": "sandwich.lg",
"schema": "sandwich.schema",
"triggers": [
"sandwich-QuantityAsk",
"sandwich-QuantitySetnumber",
"sandwich-LengthAsk",
"sandwich-LengthSetdimension",
"sandwich-NameAsk",
"sandwich-NameSetpersonName",
"sandwich-NameSetutterance",
"sandwich-BreadAsk",
"sandwich-BreadSetBreadEntity",
"sandwich-BreadEntityChoose",
"sandwich-MeatAsk",
"sandwich-MeatSetMeatEntity",
"sandwich-MeatEntityChoose",
"sandwich-CheeseAsk",
"sandwich-CheeseSetCheeseEntity",
"sandwich-CheeseEntityChoose",
"sandwich-PriceAsk",
"sandwich-PriceSetmoney",
"sandwich-CancelConfirmation",
"sandwich-CancelConfirmationSet",
"sandwich-ChangePropertyConfirmationSet",
"sandwich-CompleteConfirmation",
"sandwich-CompleteSetConfirmation",
"sandwich-CompleteSetPropertyname",
"sandwich-PropertyToChangeSet",
"sandwich-PropertyToRememberSet",
"sandwich-BeginDialog",
"sandwich-ChooseProperty",
"sandwich-HelpIntent",
"sandwich-NotUnderstood",
"sandwich-sandwichIntent",
"sandwich-ReadPropertyIntent"
]
}
From: vishwacsena <notifications@github.com>
Sent: Wednesday, February 5, 2020 10:58 AM
To: microsoft/BotFramework-Composer <BotFramework-Composer@noreply.github.com>
Cc: Chris McConnell <chrimc@microsoft.com>; Comment <comment@noreply.github.com>
Subject: Re: [microsoft/BotFramework-Composer] rfc: updated file-structure for multi-locale .lg and .lu authoring (#1922)
@vishwacsena commented on this pull request.
________________________________
In docs/rfcs/multi_locale.md<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.luolix.top%2Fmicrosoft%2FBotFramework-Composer%2Fpull%2F1922%23discussion_r375445572&data=02%7C01%7Cchrimc%40microsoft.com%7Cc8b9ea854fb74f6bf5ca08d7aa6d61aa%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637165259082601210&sdata=uQarnpOdncfP%2F0IlpnOhmgRDdlIR5XwV2045ASA%2Fu9A%3D&reserved=0>:
+ /common
+ common.en-us.lg
+ common.fr.lg
+ common.de.lg
+ Main.dialog
+/LanguageGeneration
+ Main.en-us.lg
+ Main.fr.lg
+ Main.de.lg
+/LanguageUnderstanding
+ Main.en-us.lu
+ Main.fr.lu
+ Main.de.lu
+```
+
+```
I was providing some of my personal experience working on internationalization/ localization to @cwhitten<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.luolix.top%2Fcwhitten&data=02%7C01%7Cchrimc%40microsoft.com%7Cc8b9ea854fb74f6bf5ca08d7aa6d61aa%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637165259082611209&sdata=Nl6A1RWAlKWwyf8dDLrYBxhLVMXx30oav%2BqF40pdp%2FQ%3D&reserved=0> other day. In my prior experience both on Internet Explorer as well as on Cortana, what I have seen is localization is more effective when the person localizing is enabled with three things - a) able to see full context into what's going on rather than mere strings in a text file b) able to readily test their changes c) able to always see what the base language version of the exact same string was (so they are essentially not just overwriting the base language string and then losing context into what the old string was).
So my 2c - we should not try to gate our decision to enable a purely file based localization. Instead just have the localization team use composer and use source control to reject any changes to .dialog files. In fact this was how IE was able to simultaneously ship 60+ languages on the same day as English.
With that said, @cwhitten<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.luolix.top%2Fcwhitten&data=02%7C01%7Cchrimc%40microsoft.com%7Cc8b9ea854fb74f6bf5ca08d7aa6d61aa%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637165259082611209&sdata=Nl6A1RWAlKWwyf8dDLrYBxhLVMXx30oav%2BqF40pdp%2FQ%3D&reserved=0>, few questions for option #1<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.luolix.top%2Fmicrosoft%2FBotFramework-Composer%2Fpull%2F1&data=02%7C01%7Cchrimc%40microsoft.com%7Cc8b9ea854fb74f6bf5ca08d7aa6d61aa%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637165259082621202&sdata=QhdsRltgO7YwK5H4sDBJXnkVhH%2BLoS5PNuZgJQPxVHc%3D&reserved=0>
/coolbot
coolbot.dialog
/language-generation
Can you elaborate a bit on the logic to decide to create a 'lang-locale' sub-folder? In some cases, I see this but in other cases, I see we will directly write out name.lang-locale.ext file directly.
/en-us
common.en-us.lg
Can you help clarify why .dialog file show up under LG in this case?
coolbot.en-us.dialog
/language-understanding
Same as previous comment - unclear on what logic we'd use to decide to have a lang-locale sub-folder
main.en-us.lu
/dialogs
/foo
foo.dialog
/language-generation
/en-us
foo.en-us.dialog
/language-understanding
foo.en-us.lu
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.luolix.top%2Fmicrosoft%2FBotFramework-Composer%2Fpull%2F1922%3Femail_source%3Dnotifications%26email_token%3DAEGSCMPQOLKEUU4A3YQOBP3RBMD5DA5CNFSM4KNQCY62YY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCUMQNXQ%23discussion_r375445572&data=02%7C01%7Cchrimc%40microsoft.com%7Cc8b9ea854fb74f6bf5ca08d7aa6d61aa%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637165259082621202&sdata=u82yZMSXHI%2BgdQHGULiKfHRzVftPaRGxmn29mERbYO8%3D&reserved=0>, or unsubscribe<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.luolix.top%2Fnotifications%2Funsubscribe-auth%2FAEGSCMK3XYCOVTIKBB5VRLTRBMD5DANCNFSM4KNQCY6Q&data=02%7C01%7Cchrimc%40microsoft.com%7Cc8b9ea854fb74f6bf5ca08d7aa6d61aa%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637165259082631197&sdata=IIgvVr5l3EQHig%2FBIfeN07eMe1a5pVteJDqOSiW7Bqw%3D&reserved=0>.
|
closes #1922
Multi-locale LG & LU authoring in Composer
The following RFC is intended to be guided by the following scenarios to be supported in Composer:
Implementation:
Providing a good experience to allow translations of these files can be complex. In considering the UX to provide support for language specific .lg and .lu files, we should take the opportunity to consider what has become convention for how Composer bot assets are represented on the filesytem. This RFC lays out different options to write files to disk logically and proposes an update to the current convention.
The distribution of .lg and .lu files in a set of Composer assets currently look like the following:
Problem
We want to allow an editing experience for these files as well as allow a user to add .lg and .lu in different languages and make sensible choices on the user's behalf in how we structure the asset directory.
What this would look like in today's file representation:
Issues with current file structure
"Main" became the convention to note the entry dialog, but this is a heavy constraint. We can reconsider to something more expressive. Instead of generating a
/BotName/Main.dialog, why can't we generate a/BotName/<BotName>.dialogas the entry point?Representing the .lu and .lg locally with the .dialog file is logical in that it better places the files where they are being used. This makes a Dialog directory more portable in a world where Dialogs are not only used in a single bot. This file structure is a natural place to graduate to a system where Dialogs hold their own dependencies (.lu, .lg) and can be published or shared outside of the current bot.
A example downside of this approach is that this distribution of files may not be set up for domain specific work in one of the file-formats. One could prefer that all the .lg files exist in its own directly, and all the .lg files exist in its own directory, or all "en-us" files live in an "en-us" directory, and so on. Because of the anticipation of a Dialog and its associated content files (.lu, .lg) are intended to be shared via mechanisms currently planned to be built, a structure to imply a tigher binding between .dialog, .lg, .lu is currently the preferred approach.
Note
Alternative structures
Benefit: Dependency encapsulation, recursive, convention can be applied to scenarios like publishing local dialogs and associated dependencies, or pulling down dialogs and associated dependencies from a external/third-party source.
Benefit: Physically maps to a content editing scenario (.lu, .lg)
Proposal
Important consideration:
When attempting file lookups, we should try and be agnostic to the file structure as much as possible, in trying to support the scenario where one authors these assets outside of Composer. We shouldn't limit the realistic scenario that users would wish to author files in a different text editor or IDE and load them into Composer expecting a full experience. To fully support this, we aim to utilize the Adaptive Dialog ResourceManager and supporting modules so there is near to exact parity in how the runtime and authoring surface do file lookups and resolution. Whatever we choose for a directory convention, we should not hardcode it into the resolution logic.