Feature request: redesign language picker

[konopkja]

The language picker on the website can be optimized for better UX. It is accessible from all pages in the top right menu.

Right now it contains information that is confusing to the visitors like translated word count or order by translated pages. But visitors may be interested in more logical sorting such as alphabetical so that they can find their language easier.

Word count translated isnt reflective of the amount of articles translated, therefore the metric should be changed to article counter instead.

Here is a proposal of changes
https://www.figma.com/design/H3Ih60MsjYkQrocfWsO6Ae/non-english-UX?node-id=14251-3286&t=9PmEs7kQZLarRfRa-1

These are the tasks:

• remove browser tag from UI, keep functionality
• Order languages alphabetically, instead by translation amount
• Counter should display translated pages instead of total translated words
• add custom localization logic if we detect browser language to have variable message based on language (to promote translation program)

[Anish-Gupta1]

I'd like to be assigned konopkja !

[konopkja]

Hi, ok assigning you the issue.

[Anish-Gupta1]

These are the tasks:

remove browser tag from UI, keep functionality

Order languages alphabetically, instead by translation amount

Counter should display translated pages instead of total translated words

add custom localization logic if we detect browser language to have variable message based on language (to promote translation program)

@konopkja Regarding the tasks: the first, second, and fourth tasks are completed. However, for the third task – 'Counter should display translated pages instead of total translated words' – I need some clarification. Can you tell me how I can ascertain the number of translated pages for each language? If there isn't a way to view this directly, would it be acceptable to display just the percentage of translation progress removing the word count?

[konopkja]

@pettinarip what do you think? is there an easy solution?

[gigyyy]

Hi! I'd love to work on this issue 🙌

[Anish-Gupta1]

Hi! I'd love to work on this issue 🙌

Hey appreciate the help , but I have already added 3 of the feat and waiting for pettinarip reply to guide me for the last one and after that all will be done I'll add a pr .

[gigyyy]

Hi! I'd love to work on this issue 🙌

Hey appreciate the help , but I have already added 3 of the feat and waiting for pettinarip reply to guide me for the last one and after that all will be done I'll add a pr .

Thanks for the update! I'll step aside from this one and look for another issue to contribute.

[pettinarip]

Hi! I'd love to work on this issue 🙌

Hey appreciate the help , but I have already added 3 of the feat and waiting for pettinarip reply to guide me for the last one and after that all will be done I'll add a pr .

Hey @Anish-Gupta1 yes pls, lets create a PR for those 3 things as this other request is not going to be that straightforward.

We'll need to pre-process that data at build time probably, to:

• first figure out the total number of pages, including both md pages and dynamic pages within the app router
  • for md pages, you could use the getPostSlugs function used currently to build all md pages
  • for react pags, you'll need to scan the /app directory and find all the page.tsx files
• calculate the progress for each page using the Crowdin API. This part is tricky because we don't have a direct 1:1 mapping between pages and Crowdin translations. Translations are stored in buckets, so we'd need to map page paths to these buckets. Also, pages might be composed of multiple translation files which complicates the percentage calculation

@konopkja I'd suggest leaving this point out for now and/or wait for more input from @corwintines and @wackerow

[Anish-Gupta1]

Hi! I'd love to work on this issue 🙌

Hey appreciate the help , but I have already added 3 of the feat and waiting for pettinarip reply to guide me for the last one and after that all will be done I'll add a pr .

Hey @Anish-Gupta1 yes pls, lets create a PR for those 3 things as this other request is not going to be that straightforward.

We'll need to pre-process that data at build time probably, to:

• first figure out the total number of pages, including both md pages and dynamic pages within the app router

  • for md pages, you could use the getPostSlugs function used currently to build all md pages
  • for react pags, you'll need to scan the /app directory and find all the page.tsx files

• calculate the progress for each page using the Crowdin API. This part is tricky because we don't have a direct 1:1 mapping between pages and Crowdin translations. Translations are stored in buckets, so we'd need to map page paths to these buckets. Also, pages might be composed of multiple translation files which complicates the percentage calculation

@konopkja I'd suggest leaving this point out for now and/or wait for more input from @corwintines and @wackerow

Ighty , I'll just create a PR for those 3 feat then ! Thanks