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

Initial work on language-negotiation materials #581

Open
wants to merge 20 commits into
base: gh-pages
Choose a base branch
from

Conversation

aphillips
Copy link
Contributor

I started to convert some non-prose (powerpoint) presentation materials to prose describing language negotiation. This PR is not ready to merge, as more material needs to be added and the text given a thorough edit. However, it is provided for commentary.

@aphillips aphillips requested review from xfq and r12a March 30, 2024 16:35
Copy link

netlify bot commented Mar 30, 2024

Deploy Preview for i18n-drafts ready!

Name Link
🔨 Latest commit 100eb51
🔍 Latest deploy log https://app.netlify.com/sites/i18n-drafts/deploys/67265043949dd30008c390a8
😎 Deploy Preview https://deploy-preview-581--i18n-drafts.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

@annevk
Copy link
Member

annevk commented Apr 19, 2024

I think this needs to include analysis about the potential privacy implications. In particular for minority end users.

In some sense, complete customization based on the end user's preferences is rightly an ideal, but that needs to be weighed against websites being largely unvetted applications that might not have the end user's best interests in mind.

@aphillips
Copy link
Contributor Author

I think this needs to include analysis about the potential privacy implications. In particular for minority end users.

@annevk Thanks for the comment.

This material was written from the point of view of a website owner/developer, so, of course, doesn't currently include such considerations. That said, it probably should have already included some admonition about not exposing user preferences to third parties.

I agree that privacy implications need to be addressed and will add some text about that shortly. Comments/suggestions welcome.

@xfq
Copy link
Member

xfq commented Apr 28, 2024

The scope of this article seems to have some overlap with our existing article, both covering when language negotiation should be used. The existing article contains more examples.

Should we probably introduce the concept of language negotiation in this article, and introduce when we should use language negotiation in our existing article?

- Retitling the headers
- Making the core flow better
- Remove redundant information about why locales
- group the list by type of signal
- rephrase helpfully
- add a note about not inferring locale from region etc.
- fix badly indented bullet item
- remove note/example formatting
@xfq
Copy link
Member

xfq commented Jul 9, 2024

This document seems to discuss both "language negotiation" and "locale negotiation". If these two terms have different meanings, it might be useful to point them out clearly so that readers will feel clearer. If not, it would be best if we could use consistent wording.

@aphillips
Copy link
Contributor Author

This document seems to discuss both "language negotiation" and "locale negotiation". If these two terms have different meanings, it might be useful to point them out clearly so that readers will feel clearer. If not, it would be best if we could use consistent wording.

These terms don't have different meanings. The problem is that "language negotiation" is the common term, while "locale negotiation" is more accurate.

It's a good callout that I don't define the terms and pull them together early in the document. See 5950acd for fixes.

Comment on lines 239 to 240
> i. For each language range in the A-L header
> a. if the language range matches an available locale's language tag, let return value be that locale
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Markdown doesn't seem to support list syntax like i. or a..

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes: the article will be converted to HTML before final publication.

@klensin
Copy link

klensin commented Jul 27, 2024

Sorry... long overdue and most of this is nitpicking. I'm trying to transcribe notes from about 10 days ago rather than letting it go longer; hope the result is sufficiently clear.

(i) Probably the first use of "language tag" should be a link to BCP 47. Please do not link just to the registry
(ii) 2nd paragraph, first example or earlier: mention impact on trying to compare one instance of a string with might be another instance.
(iii) Bullet list "Determining...". IP addresses are increasingly unreliable for determining locations or much of anything else other than the address itself The problems arise from efforts to deal with the shortage by NAT mapping before the destination LAN (e.g., with CGNAT), assorted 4to6 and 6to4 mappings), and assorted privacy-driven efforts. No need to go into that in the document, just be careful about mention of determining local from addresses.
(iv) Text about the simplest case, "persist" should probably be "preserve".
(v) The last section is really not clear. In particular, the user should probably be given an explicit choice.

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.

4 participants