I am developing a Blazor hosted WASM app with individual accounts, that by default uses Duende Identity Server. It works, but all the account management pages and messages are in English when I need them to be in French (I don't need a multilanguage version).
I found that to translate them, I can add the scaffolded Razor pages to the server project.
Now, I can translate the texts in the generated pages, but that brings a few questions:
Has anyone (Microsoft?) already done that quite standard localization work? Would it be available to use?
Texts to be translated are located in different locations: inline in the HTML, in data annotations... it's not easy to not forget any of them.
Some messages (i.e. "You are logged out") seem to be buried into the DLLs, so I didn't find how to translate them.
I couldn't find many resources on the subject on the Internet, so any hints would be much appreciated.
Related
Hello EveryOne I'm New To Umbraco I did Some Simple Umbraco Sites and Im good with so far Based on my Humble .Net background My Question is : How can i Remotely Change the Content of My umbraco form Other Pc or Something like that using Web service or APIs or what ever Im Looking foreword For a Good answer
Thanks In Advance
Depending on your needs, you can create a webapi on top of your Umbraco instance. You'll have to implement the actions yourself.
See this reference on how to implement it
Another option is installing Umbraco Rest API. This will add functionality for managing content and media through a rest service. Haven't tried this plugin myself, so no clue if works in the current version.
Some additional information can be found here
I need to simply do this:
I need my application to use OAuth to get a user's full name, email address, gender and date of birth from Google.
I've got the whole deal about how to use OAuth. I've got the workflow and I could myself use the HttpWebRequest or the HttpClient to make requests myself and do it the raw way, which I actually prefer.
But, just to be safe, I want to use the Google API Dot Net Client. I have been reading through the vast amount of documentation about using this monstrous thing and I can't figure out a few basic things:
1) Which Google API do I need to use? Just the Google OAuth API will do? I see in the google dot net client library samples that they all get data from other Google services such as the Drives or Books services/APIs.
If I need just the basic information such as full name, email, gender and date of birth, which service do I need to query using the Google OAuth API?
2) Which NuGet package must I install? There're plenty of them with roughly the same names.
I've read a ton of stuff in the last 2 days about this and there are about 28 tabs open in my browser about this. The more I read, the more it adds to my confusion.
The NuGet package pages on the nuget website have no documentation at all. They must clearly state the purpose and the extent of services that the package provides. The latter is clearly missing. They all seem to have the same one line description instead, which is totally unhelpful.
I even took the source for the google-api-dot-net-client and tried compiling it. I didn't even know which Visual Studio version it was going to open in. I read the solution files in Notepad and they suggested that the version of 2012. So when I opened the solution in Visual Studio for Web 2012 Express, many projects did not open; it said they were incompatible with the version of Visual Studio. Also, the dependencies/references weren't loaded correctly.
I am using Windows 7 Home Premium. I've got Visual Studio Express versions from 2008 to 2013.
I need to use the OAuth API in an ASP.NET MVC application. I've seen various samples. I just need to know the basic set up information such as which binaries and which NuGet packages I need to get and from where.
Update
Hurray to hand-plumbing. I'm doing it by hand. Ditch the .NET client.
All Google.Apis NuGet packages are auto generated. As you can see there are packages for Drive, YouTube, Plus, Storage, AdSense, etc. You can read more about each package in our developers.google.com site. Take a look at the following:
https://developers.google.com/api-client-library/dotnet/ - Contains all the documentation for the .NET client library for Google APIs.
https://developers.google.com/api-client-library/dotnet/apis/ - Contains all the different Google APIs and several references to the API documentation, how to download it using NuGet, etc.
Check out our https://developers.google.com/api-client-library/dotnet/guide/aaa_oauth page. It contains a lot of information about the OAuth 2.0 protocol and several snippets
In addition, just to let you know, you don't need to use any of that:
https://code.google.com/p/google-api-dotnet-client/source/browse/ contains only the core library code that is shared between all those different APIs. All APIs shared the same OAuth 2.0 protocol, the same HTTP components, the same media upload and download mechanism and so on. Every week I update the NuGet packages by running the NuGet publisher.
Hope it makes sense now.
I am about to start building a mobile site which is dynamic, working from a lot of dynamic content which must come from the database.
I have already written a REST API for the site which the IOS and Android applications are using to interact with the information.
My question is what would be the absolute best practise for building this site, would it be:
1- Make the mobile classes an extension of the existing site functions
(The downside I see here is that the mobile site would be dependant on the main site library meaning that any bad heat on the main site would also affect the mobile site)
2- Make the mobile site a completely stand alone site running from itself
(The downside I see here is that any change to the main site library will need to be reflected here so in essence we would almost be writing code twice)
3- Make the mobile site run from the REST API and standalone
(The downside i see here is just increased number of HTTP requests for the information rather than communicating with the server directly)
Each one would function normally and there wouldn't really be any problem there, coding is really not too difficult, though if I make it standalone I would need to recreate a lot of the functions from the main site and adapt them for the mobile site which isn't ideal.
Look forward to your comments! Thanks
I would go with 3rd point, but that needs to be architect well.
We will prioritize standalone application after that API, also we can have 2 way communication, any content changed on server it will coordinate with clients to get that updated.
Also I would also suggest go with Bootstrap framework, its an awesome framework and have responsive and adaptive design
Disregarding my question I asked earlier (and deleted) which has been solved, I want to know, how do I force sharepoint to generate user-friendly my site collection URLs?
To make the question easier, I'll include an example.
http://spaces.companyspttest.biz/Person.aspx?accountname=ADtest\Eon
must become
http://spaces.companyspttest.biz/Eon
How do I do this?
Ok, seems like what I have been looking for is a Self-Service Site Creation.
To activate it , go to Web applications management in Central Administration in Sharepoint, ,Select the web application which requires this "Shortened URL",Click Self Service Site Creation in the ribbon, and turn it on.
After that, add a Managed path to the web application called Profiles.
Not 10000% what I wanted regarding the URL, but definitely the page I wanted to see when I type the URL.
I really like the new feature, Web API that's released with MVC4.
I'm currently working on a web application, that I will want to extend it to a mobile application.
What would be the best way of utilizing this feature?
Program it like there's no Web API, and when i'm ready to develop for a mobile application, then use this feature (Copy and paste controller functions then edit the return and error handling value ?
Or should I use Web API from the beginning of the web development. Using javascript to call functions and to handle errros? The problem with this apporach is I'm not too familiar with JS, and the code would not look very clean (the Views)
Any opinion?
Thanks
IMHO the Web API shouldn't be seen as a feature specific to mobile application development. It's a tool allowing you to easily expose RESTful APIs over HTTP. Those APIs could be consumed from desktop applications, web applications, mobile applications, etc ... The interface for each type of application will of course be developed using the specific frameworks and tools for this task (WPF, ASP.NET/MVC, WP7/iOS/Android, ...).
The Web API just allows you to expose your business data and services in an interoperable way so that different clients could consume them.
I would prefer using the second approach.
In the beginning, I also thought the .ajax calls might mess up the Views. (No one likes to add a long <script> section in a View.) But after asking my questions on Stackoverflow, I am glad to find some experts here using some "code-behind" for those javascript.
The practice is:
Create a separate JS folder to store all the "code-behind" js files. (The default Scripts folder only contains the third-party packages like knockout.js, jquery.js and etc)
For each view, generate a .js file, like home.index.js, form.add.js, etc. Just follow a consistent rule. There will be a lot of js files created. The great thing is in MVC4, we can combine all .js files under this folder and generate a minified, combined, single file, and load it only once in the _Layout view.
The way to do it is:
In _Layout view, <head> section:
<script src="#System.Web.Optimization.BundleTable.Bundles.ResolveBundleUrl("~/JavaScripts/js")" type="text/javascript"></script>
In Global.asax, Application_Start, register the bundle:
var bundle = new Bundle("~/JavaScripts/js", new JsMinify());
bundle.AddDirectory("~/JavaScripts", "*.js", true);
BundleTable.Bundles.Add(bundle);
BundleTable.Bundles.EnableDefaultBundles();
//BundleTable.Bundles.RegisterTemplateBundles();
Then you are good to go. The Views are still clean. All the .js files are organized. And no need to import different .js file on each individual view.
Leaning JS is not a problem. As it is probably the only client-side programming language, it is now becoming necessary for us to learn new things. And I feel it is easier since we have jQuery now. It is time to upgrade our knowledge. I am happy and excited about what we can accomplish with these new tools.