Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ESM support #180

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

ESM support #180

wants to merge 3 commits into from

Conversation

Zurdge
Copy link

@Zurdge Zurdge commented May 3, 2024

@AlexMost
Been using ttag recently, was disappointed gettext couldn't support my Javascript/Typescript codebase.

Just experimenting with the babel plugins, not written any babel plugins before so your feedback would be very helpful 🙏


Changes to /src

My thinking is that if we've got a ImportDeclaration which passes the if (!isTtagImport(node)) return; then we cna be pretty sure there is an intent from the developer to be using ttag for localization.

Rather than throwing You should use ttag imports in form: "import { t } from \'ttag\'" we can import the default alias names so that we can catch t, gettext, ngettext,...

Tests added

[Will update..]

@Zurdge Zurdge marked this pull request as draft May 3, 2024 01:19
@Zurdge Zurdge marked this pull request as ready for review May 3, 2024 02:14
@Zurdge
Copy link
Author

Zurdge commented May 3, 2024

Have been looking at this for a little bit 😅
Wondering if it might be easier and more customizable for developers if the plugin decoupled the links between the ExpressionStatement names such as t, gettext, ....
At the moment context.addAlias and context.addImport are used to kind of register the nodes into the context.

Could let developers define the ExpressionStatements in come kind of config .ttagrc which might look like

{
    'tag-gettext': ['t', 'myCustomMethod'],
    'jsxtag-gettext': ['jt'],
    gettext: ['gettext'],
    ngettext: ['ngettext'],
    msgid: ['msgid'],
    context: ['c'],
}

Would be quite a big refactor though (almost new plugin), wondering if there has been any thoughts/development in the direction already?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant