opral / monorepo Goto Github PK

Describe the bug

Rollup polyfills for memfs seem to have a wrong setup. Development works, likely because vite uses esbuild for the dev server, while the build command, which uses rollup, fails.

'extname' is not exported by __vite-browser-external, imported by ../../node_modules/@rollup/pluginutils/dist/es/index.js
@inlang/website:build: file: /Users/samuel/Documents/GitHub.nosync/inlang/node_modules/@rollup/pluginutils/dist/es/index.js:1:9
@inlang/website:build: 1: import { extname, win32, posix, isAbsolute, resolve } from 'path';

To Reproduce
Steps to reproduce the behavior:

1. run npm run build

Expected behavior

The build runs successfully.

Additional context
Add any other context about the problem here.

Describe the bug
I can't change the language on the Landing page.

To Reproduce
Steps to reproduce the behavior:

1. Go to '.https://inlang.dev/'
2. Scroll down
3. Click on 'English'
4. Click on 'Deutsch'
5. The language did not change.

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• . iOS
• Browser . chrome,]

Related RFC:

• #128

React for example differs vastly from NextJs although it should be identical.

The editor requires an overhaul due to architectural changes laid out in #127.

This issue's purpose is to define a feature set and track the corresponding progress on those features.

• #142
• #143
• #135
• #136
• #137

The following features are likely out of scope:

• #138

I just spent 10 hours on a bug that would have been obvious if implicit any's would cause linting errors. Reminder to myself to add "noImplicitAny" to the typescript config

It comes in handy if the vscode extension automatically strips quotation marks from patterns/strings.

Example

const x = "hello world"
-> highlighting "hello world"
-> strip ""
-> only extract hello world

Front conversations

The ast package is powering every other package or app of inlang. See #127

The IDE extension requires an overhaul due to architectural changes laid out in #127.

This issue's purpose is to define the minimum feature set and track the corresponding progress on those features.

• #132
• #133

		// TODO changes that have been pushed are shown as unpushed

https://github.com/inlang/inlang/blob/7452455d75ac49daeeb57d947ab5dfe962c4d408/source-code/website/src/editor/pages/@host/@organization/@repository/state.ts#L237

Intro

The current implementation relies on Server Side Rendering (SSR) to fetch a JSON file over a network request which contains the translations. This has the severe downside of requiring a server-side framework like NextJS or SvelteKit for inlang to work. Furthermore, the security of fetching the translations is not rigid. Anyone can fetch any translations by using the domain of the app.

TLDR

• relies on SSR, thus requiring special frameworks like NextJS, SvelteKit and a special SSR step e.g. using load() in svelteKit or getStaticProps in NextJS.
• security risks that come with fetching translations via a network request

Proposal

The GitHub repo of a certain app can be used directly as "storage" for the translations. Using the source code directly eliminates the need to make a network request, thus the need for an SSR framework and potential security risks.

Pros

• no network request, no SSR required(?)
• no network request, less security issues
• changing the translations in the source code without the need for a dashboard

Cons

• No dynamic updating of translations. (Re-add network request as a feature in the future?). Important for Native Apps which must submit a new version of the app each time the translations should update.

"surface-100": new TinyColor(neutralColors.neutral[900])
			.setAlpha(0.05)
			.toHex8String(),

setAlpha well sets the alpha. remove setAlpha and likely TinyColor altogether.

Describe the bug
On the README, clicking Blog or documentation leads to a 404 on inlang.dev

To Reproduce
Steps to reproduce the behavior:

1. Load Github readme2.
2. Click blog or documentation

I get the following error if I try to use inlang in my sveltekit project.

500
__vite_ssr_import_1__.loadTranslations is not a function
TypeError: __vite_ssr_import_1__.loadTranslations is not a function
    at load (__layout.svelte:9:38)
    at load_node (file:///Users/swelsch/Development/b-nova/breedium/frontend/node_modules/@sveltejs/kit/dist/ssr.js:957:30)
    at respond$1 (file:///Users/swelsch/Development/b-nova/breedium/frontend/node_modules/@sveltejs/kit/dist/ssr.js:1242:21)
    at async render_page (file:///Users/swelsch/Development/b-nova/breedium/frontend/node_modules/@sveltejs/kit/dist/ssr.js:1433:19)
    at async resolve (file:///Users/swelsch/Development/b-nova/breedium/frontend/node_modules/@sveltejs/kit/dist/ssr.js:1696:10)
    at async Object.handle (/Users/swelsch/Development/b-nova/breedium/frontend/src/hooks.ts:14:24)
    at async respond (file:///Users/swelsch/Development/b-nova/breedium/frontend/node_modules/@sveltejs/kit/dist/ssr.js:1675:10)
    at async svelteKitMiddleware (file:///Users/swelsch/Development/b-nova/breedium/frontend/node_modules/@sveltejs/kit/dist/chunks/index.js:4531:22)

I did npm install inlang --save and my __layout.svelte file looks like

<script lang="ts" context="module">
	import Header from '$lib/header/Header.svelte';

    import { setTranslations, loadTranslations } from 'inlang';

    export async function load({ page }) {
        if (page.params.lang) {
            setTranslations(
                await loadTranslations({
                    projectDomain: 'demo.sveltekit.inlang.dev',
                    locale: page.params.lang
                })
            );
        }
        return {};
    }
</script>

// TODO extract tableOfContents to separate file?

https://github.com/inlang/inlang/blob/44ae551765c6c93844b8aa6f00f07fb79071c33d/source-code/website/src/pages/documentation/index.page.tsx#L7

Describe the bug
A clear and concise description of what the bug is.

**
To Reproduce**
Steps to reproduce the behavior:

1. Go to languages
2. Click on delete

Expected behavior
Deleting the language

Screenshots

Describe the bug

Icon mismatch/design bug when opening the dropdown in website-and-editor branch on the homepage.

The editor clones a whole repository. Especially for private repositories, file-based access control is desired. A translator should only be able to clone translation relevant files.

Describe the bug
When trying to install the CLI via NPM, I get an error message that the package is not found.

To Reproduce
Steps to reproduce the behavior:

1. Create a new folder
2. Run npm init -y
3. Run npm i @inlang/cli -D
4. See error:

npm ERR! code E404
npm ERR! 404 Not Found - GET https://registry.npmjs.org/@inlang%2fcli - Not found
npm ERR! 404 
npm ERR! 404  '@inlang/cli@*' is not in this registry.
npm ERR! 404 You should bug the author to publish it (or use the name yourself!)
npm ERR! 404 
npm ERR! 404 Note that you can also install from a
npm ERR! 404 tarball, folder, http url, or git url.

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/ben/.npm/_logs/2022-03-25T08_22_13_677Z-debug-0.log

Expected behavior
The package should be in the registry and install.

Desktop:

• OS: MacOS
• Node Version: v17.4.0

To ease development in the team, and ease external contributions, have one development environment with https://www.gitpod.io/.

The config package powers all apps of inlang. See #127

The html documents language could be used as language detection.

Create a documentation site.

// TODO lazy load layouts
// see https://www.solidjs.com/tutorial/async_lazy

see https://www.solidjs.com/tutorial/async_lazy

https://github.com/inlang/inlang/blob/8c4079d53bb77586bdde380e1414bdfff9a9b1f4/source-code/website/src/renderer/PageLayout.tsx#L4

This page says translations can be converted with converters when downloading formats other than fluent.

Is there any existing converter? I couldn't find info regarding existing options.

Or is that wip?

The ide extension opens a generic link to the github repo. #151 is done, add correct link.

Whats an enhancement?

Source-code-configs contains no source-code. Move config files out of the directory?

Describe the enhancement
A clear and concise description of what the enhancement is about.

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

Show the CLI command to export/import translations in the export/import tabs.

**Describe **

The defined subset of the node fs in the config is incompatible with node:fs/promises.

Expected behavior
Node's promise-based fs type should be compatible with the defined fs type in the config.

Screenshots

Additional context
Add any other context about the problem here.

Extending on #103

Smart extraction of string interpolation:

Allow selecting `Hello, ${userName}` for extraction.
When extracting it should generate Hello, {$userName} in the ftl file. And in code it should pass userName as a parameter.

The VS Code extension looks for the inlang.config.json file in the first workspace folder (and fails if it is not found there). This makes it difficult to use Inlang in a multi-root workspace if the repo using Inlang is not in the first workspace folder (requires moving or linking the config file to the first folder) and impossible to use Inlang with different configurations in different folders of a multi-root workspace.

Maybe:

https://github.com/inlang/inlang/blob/cf6c11e731909f508fc8b28ada2e6389b47d7212/packages/inlang-vscode-extension/src/extension.ts#L26

could be replaced with something like:

const openedDirectoryPath =  vscode.workspace.getWorkspaceFolder(vscode.window.activeTextEditor.document.uri).uri.fsPath;

which would look for the inlang.config.json file in the workspace folder that contains the file opened in the active text editor. That way each workspace folder in a multi-root workspace could have its own config file.

Possibilities:

• https://shoelace.style/
• https://www.fast.design/

Other systems rely on a framework like React, Svelte, etc. Choosing other systems relies on #142

Searching through the messages updates the rows, but not the underlying patterns. I assume that the patterns array is not filtered. Accessing a pattern with the row index likely leads to that issue i.e. patterns[index]

The outline colors are not matching

Problem

The nav bar and editor seem visually too close. Both make use of a horizontal divider and no color difference between them.

Proposal

Increase visual difference by either changing the nav bar or the "editor nav bar". GitHub only uses color.

We could use surface-100 for the nav bar. I played around with surface-100, a bit too light. The hue likely needs to increase in the color system to make a meaningful difference.

See #101

Warn the user that local, or remote, translation files are going to be over-written.

This feature exists in the current vs code extension already but will be re-implemented in anticipation of the architectural changes laid out in #127.

Contributing via OAuth flows (see #136) does not work for external contributors or repositories a translator has no access to. An alternative for public repositories could be GitHub's fork functionality. The editor forks a public repository either on behalf of the user or by creating an inlang-fork/repository fork for all external contributors.

More ideas are welcome.

Hello,

Since the files are all here, it would be nice to have a setup documentation for them. Better yet if you packed the dashboard components under a single docker-compose project.

inlang.config.json also needs a server host field

looping over all bundles and their resources is a performance bottleneck

const messages = bundle.resources.flatMap((resource) => resource.body);
const message = messages.find((message) => message.id.name === args.id);

Instead, the query function could be created with a const query = createQuery() function that holds an index (hash table) of messages to speed up querying e.g. instead of looping through resources, a more efficient query would be

bundles[bundleId].resources[resourceId].messages[messageId]

https://github.com/inlang/inlang/blob/eb038be273e0a56e11eff97e153525a70ed4ae9e/source-code/core/src/query/index.ts#L99

/c:/Users/Nate/Desktop/my-app/inlang.config.json is a UNIX path.

This feature exists in the current vs code extension already but will be re-implemented in anticipation of the architectural changes laid out in #127.

			{/* TODO: use proper text editor instead of input element */}

https://github.com/inlang/inlang/blob/bb68497d29debe803b34c4bfc28a8056184f199c/source-code/website/src/editor/pages/@host/@organization/@repository/Messages.tsx#L124

The pattern editor uses an input element right now. Use an editor like https://github.com/facebook/lexical in the future to render placeholders and not only text.

The pattern:

{ $count ->
     [one] Language
    *[other] Languages
}

As displayed in VS Code

The initial version of the inlang editor should use existing git auth workflows. In other words, use OAuth flows to act on the behalf of the user.

This implementation only requires the user to "login" with a git provider and et voila, the user can contribute.

One of the big problems of i18n is no existent type safety. https://github.com/ivanhofer/typesafe-i18n is gaining momentum as one of the first solutions that enable typesafety for i18n. It requires setup and continuously watches the translation file to auto-generate type annotations.

Inlang currently posts missing translations via a network request. That is already better than most wide-stream i18n solutions but also has downsides:

1. During development, the missing translations can become convoluted. A developer might wrote a typo "hrllo" instead of "hello" which the dev fixes after 1 min but it's too late "hrllo" and "hello" are posted and tracked as missing translations. One way to avoid that is using ids t('hrrlo', {id: 'compenent.hello'} .
2. Even if id's are used, the translation for 'component.hello' might not exist yet. In other words the DX can be improved by showing a linting error that the translation key does not exist yet. And instead of baking a network request into the t function, a VSCode extension could do that job. I currently imagine the linting error, when hovering over the error a small popup from the inlang-vscode extension shows with a simple "add to translations" button.

Regardless of how missing translations are tracked. Typesafety is even better for variables t("Hello {user}", vars: { uset: "Samuel" }) is a runtime error. The type uset is not statically caught. Neither would be something like t("Hello {userId:number}", vars: {userId: "Samuel"}` userId is expected to be a number but a string is passed. As a matter of fact, that will not even be a runtime error.

TLDR

Exporting statically typed translation files into the source repository instead of json files can greatly improve DX.

Automatically created from Linear (#25)

via LinearSync

Supabase supports row level security on subscriptions now. No need to use the current workaround with the projectStore anymore + polling (which already lead to bugs.).

Technically not required for project dog food (https://github.com/orgs/inlang/projects/7) but a landing page with documentation should be available.

• #151