Should the page names like "Home", "Counter", "Fetch data" be localizable? If yes, no changes needed. If not, then it would be great if those terms can be blocked from localization by using either in-line code, or no-loc custom syntax.
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
Yes, they should be blocked because AFAIK the templates aren't translated in any way.
I'll use in-line code because these might be translated in other contexts.
@Rick-Anderson @scottaddie @wadepickett Seems like under the latest thinking that we should be code fencing ...
_Host.cshtml)Pages)Counter page)wwwroot/css).razor)In terms of the IDEs, it's difficult to know what changes for our UI text references. I theoretically can set VS to another language and back and :pray: hopefully not get hosed :pray:, but I don't really want to risk it.
I felt a safer changing the language on my iMac. Interesting outcome ...
The IDE is variable, but the list in my last comment :point_up: looks right for code fencing changes.
@Rick-Anderson @scottaddie @wadepickett I'll be working on this soon. Has a decision been made on what to code-fence ... is the list that I posted correct? :point_up:
btw- Every hand is against me on using the en dash as a layout element. I think it looks great, including in multiple languages ... and with the MT engine leaving it alone.
Well ... beaten down and busted up 🥊🤕 ... I'll accept the colon. I'll be changing over to colons for existing usages of the en dash as a layout element and using the colon going forward.
I don't think there's much problem with Home. I suggest some time in the past, when updating a doc, look at the doc in another language. I look at spanish and german. Usually problems like this jump out.
The app won't be localized, so the sidebar navlink will render "Home" for link text.
@JasonCard ... Code-fence package names, correct? For example ...
Microsoft.AspNetCore.SignalR.Client
@guardrex Yes, I agree.
:smile: ...
\*.*\*
... is rapidly becoming my favorite RegEx on this issue.
We've already gone a little bit down the slippery slope of styling link text. The manual says 'don't do it,' but we're likely going to need to in some cases if we don't use the no-loc metadata for a given topic. I caution against using no-loc in specific topics because that will eliminate the possibility of performing a massive find-'n-replace on that line to add something to the list for every topic.
Another challenge is bold text for UI that we also want to code-fence to avoid loc. The Blazor app template has a counter button with text of "Click me" on a button. We'd normally put that in bold (**Click me**) in the doc text because it's a UI element. Because template text isn't translated, I guess that I'll need to attempt both with:
**`Click me`**
EDIT WRT that :point_up:, I'm going to commit the updated Blazor tutorials, the Build your first Blazor app and Blazor with SignalR topics, to the repo, take them live, and inspect how those get rendered. I'll report back here on the result.
EDIT 2X Yes! ☝️ It ✨ _Just Works!_:tm: ✨
I've also seen that some VS UI is translated and other text isn't. I probably can't go that far with this round of updates. I'll need to go with English for VS UI, which I know isn't correct. I'm not going to have time to get that deep into the weeds on this pass.
We've already gone a little bit down the slippery slope of styling link text. The manual says 'don't do it,'
Unless there's a risk of over-localization, then do it. Same with hard coded file names like wwwroot.
Yes, I'll continue with it. :point_up:
WRT bold and code-fencing, it seems ok.
Before:
After:
How do you do bold code fenced?
Like this ...
**`Add todo`**
Rendered example at Step 8 ...
https://docs.microsoft.com/en-us/aspnet/core/tutorials/build-your-first-blazor-app?view=aspnetcore-3.1#build-a-todo-list