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

Feature Request: Add language to Routing. #501

Closed
cchatham opened this Issue Mar 19, 2015 · 25 comments

Comments

Projects
None yet
4 participants
@cchatham
Contributor

cchatham commented Mar 19, 2015

Hey guys,

I love the fact that the localization is based on the user's browser. However, I have read that it is better for SEO to be able to link to the different languages that the site supports. So technically someone who speaks English but lives in France would land on the French site. Then this user could change to English with one click.

I know how complicated this would be with how the routes are implemented currently. I just wanted to get your thoughts.

@blakecallens

This comment has been minimized.

Show comment
Hide comment
@blakecallens

blakecallens Mar 19, 2015

Member

@brianhyder will be the ultimate voice on this, but I'll chime in.

The localization service's language can be set by the application, so it's possible for pathVars in your plugins' routes to change it on the controller level.

Member

blakecallens commented Mar 19, 2015

@brianhyder will be the ultimate voice on this, but I'll chime in.

The localization service's language can be set by the application, so it's possible for pathVars in your plugins' routes to change it on the controller level.

@brianhyder

This comment has been minimized.

Show comment
Hide comment
@brianhyder

brianhyder Mar 19, 2015

Member

I think that we can assist with solving this problems by taking some cues
from https://support.google.com/webmasters/answer/189077?hl=en

We could probably make it as easy as having a global query parameter that
sets the language. Either way we should denote the supported languages for
each page based on the loaded language sets. Need to do a little more
research but I don't know that we would provide language specific url paths
out of the box but would ensure we provide the ability to bake that in via
plugin.

@brianhyder https://github.com/brianhyder will be the ultimate voice on
this, but I'll chime in.

The localization service's language can be set by the application, so it's
possible for pathVars in your plugins' routes to change it on the
controller level.


Reply to this email directly or view it on GitHub
#501 (comment).

Member

brianhyder commented Mar 19, 2015

I think that we can assist with solving this problems by taking some cues
from https://support.google.com/webmasters/answer/189077?hl=en

We could probably make it as easy as having a global query parameter that
sets the language. Either way we should denote the supported languages for
each page based on the loaded language sets. Need to do a little more
research but I don't know that we would provide language specific url paths
out of the box but would ensure we provide the ability to bake that in via
plugin.

@brianhyder https://github.com/brianhyder will be the ultimate voice on
this, but I'll chime in.

The localization service's language can be set by the application, so it's
possible for pathVars in your plugins' routes to change it on the
controller level.


Reply to this email directly or view it on GitHub
#501 (comment).

@cchatham

This comment has been minimized.

Show comment
Hide comment
@cchatham

cchatham Mar 23, 2015

Contributor

So here is what I keep reading in a lot of places:
http://webmasters.stackexchange.com/questions/403/how-should-i-structure-my-urls-for-both-seo-and-localization

We might be able to do this at the top level domain which would make things a little easier I think. Definitely should be a plugin because not every site needs this. Any advice on the best way to overwrite the global routes with minimal breakage?

Thanks for all the help!

Contributor

cchatham commented Mar 23, 2015

So here is what I keep reading in a lot of places:
http://webmasters.stackexchange.com/questions/403/how-should-i-structure-my-urls-for-both-seo-and-localization

We might be able to do this at the top level domain which would make things a little easier I think. Definitely should be a plugin because not every site needs this. Any advice on the best way to overwrite the global routes with minimal breakage?

Thanks for all the help!

@brianhyder

This comment has been minimized.

Show comment
Hide comment
@brianhyder

brianhyder Mar 23, 2015

Member

I don't think there is a great way at the moment to do this without changing core code to hook into:

  • functions for generating redirect URLs
  • functions for dynamic site roots
  • picking appropriate language based on session values or incoming URL

I think the answer lies somewhere in the above. Not exactly sure how it all fits together just yet. Adding the routes for all of the pages wouldn't be hard. You would just look at all of the available languages and register all paths for those. It is setting the language based on anything but the accept-language header that isn't baked into the code. We also don't currently have a baked in mechanism for populating the meta tags that would tell search engines how locales/languages relate to other URLs

Member

brianhyder commented Mar 23, 2015

I don't think there is a great way at the moment to do this without changing core code to hook into:

  • functions for generating redirect URLs
  • functions for dynamic site roots
  • picking appropriate language based on session values or incoming URL

I think the answer lies somewhere in the above. Not exactly sure how it all fits together just yet. Adding the routes for all of the pages wouldn't be hard. You would just look at all of the available languages and register all paths for those. It is setting the language based on anything but the accept-language header that isn't baked into the code. We also don't currently have a baked in mechanism for populating the meta tags that would tell search engines how locales/languages relate to other URLs

@blakecallens

This comment has been minimized.

Show comment
Hide comment
@blakecallens

blakecallens Mar 27, 2015

Member

Maybe we can add this as a content setting, where if you turn it on, the base site url becomes [siteRoot]/:language and the core routing logic sets the localization language based on that.

Member

blakecallens commented Mar 27, 2015

Maybe we can add this as a content setting, where if you turn it on, the base site url becomes [siteRoot]/:language and the core routing logic sets the localization language based on that.

@brianhyder

This comment has been minimized.

Show comment
Hide comment
@brianhyder

brianhyder Apr 2, 2015

Member

Blake and I talked about this tonight. We have a tentative plan for putting this together for Q2. We'll post the roadmap in the coming weeks.

Member

brianhyder commented Apr 2, 2015

Blake and I talked about this tonight. We have a tentative plan for putting this together for Q2. We'll post the roadmap in the coming weeks.

@cchatham

This comment has been minimized.

Show comment
Hide comment
@cchatham

cchatham Apr 3, 2015

Contributor

I apologize for not getting back sooner. Lots of meetings on this side. I love the ideas and this isn't the highest priority for us, but we will have to decide from a business perspective how we want to handle multilingual customers.

Again thanks for the ideas! If we need to take this on as a plugin, let us know.

Contributor

cchatham commented Apr 3, 2015

I apologize for not getting back sooner. Lots of meetings on this side. I love the ideas and this isn't the highest priority for us, but we will have to decide from a business perspective how we want to handle multilingual customers.

Again thanks for the ideas! If we need to take this on as a plugin, let us know.

@blakecallens

This comment has been minimized.

Show comment
Hide comment
@blakecallens

blakecallens Apr 3, 2015

Member

The plan, for now, is to have this as a core feature in the Q2 roadmap, with the settings living in config.js.

Member

blakecallens commented Apr 3, 2015

The plan, for now, is to have this as a core feature in the Q2 roadmap, with the settings living in config.js.

@cchatham

This comment has been minimized.

Show comment
Hide comment
@cchatham

cchatham Apr 27, 2015

Contributor

This sounds fabulous! I am assuming it will follow the standards below:

#1 - http://en.wikipedia.org/wiki/List_of_ISO_639-1_codes
#2 - http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2

Combined to /#1-#2/

Thanks so much!

Contributor

cchatham commented Apr 27, 2015

This sounds fabulous! I am assuming it will follow the standards below:

#1 - http://en.wikipedia.org/wiki/List_of_ISO_639-1_codes
#2 - http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2

Combined to /#1-#2/

Thanks so much!

@brianhyder brianhyder added this to the 0.5.0 milestone Jul 19, 2015

@brianhyder brianhyder added the ready label Oct 20, 2015

@brianhyder brianhyder self-assigned this Oct 20, 2015

@brianhyder brianhyder added in progress and removed ready labels Oct 21, 2015

@brianhyder

This comment has been minimized.

Show comment
Hide comment
@brianhyder

brianhyder Oct 21, 2015

Member

Design:

We need to support localized routes in order to be more SEO friendly. This means that:

https://careerbuildercareers.com/
https://careerbuildercareers.com/en-us

will go to the same location and will provide English (assumes that the default locale is
set to en-US). The design will also provide functionality such that when provided:

https://careerbuildercareers.com/es-es

the site will provide the same location as the URLs denoted above but localized to Spanish.
The existence of the route parameter will prioritize setting the user's locale for the
request by the locale in the route above retrieving it from the user setting and
accept-languages header. In the case of localized routes such as home pages where a
locale is not provided the locale will be chose by the user preference or fall back to the
accept-languges header.

Each route (page or view) must identify itself as "localized" in the route's definition.
An example is provided below:

    SomeViewController.getRoutes = function(cb) {
        var routes = [
            {
                method: 'get',
                path: "/about",
                handler: "render",
                content_type: 'text/html',
                localization: true
            }
        ];
        cb(null, routes);
    };

The above "localization" property set to true will indicate that the route should be
registered multiple times; one for the route with out a locale prefix and one for each of
the supported locales. Therefore, the above route definition would result in the
following routes (NOTE: this is not exhaustive and is bound by the locales available at
startup):

https://careerbuildercareers.com/about
https://careerbuildercareers.com/en-us/about
https://careerbuildercareers.com/es-es/about
https://careerbuildercareers.com/po-po/about

The first version will not attempt to resolve or detect cases where routes are defined
explicitly with locales in the route definitions. The first version will also not support
the ability to specify which locales are available to the route at time of definition.

When a route is registered and the localization property is enabled (FALSE by default) the
RequestHandler will prefix the route with a route parameter ":locale". During route
evaluation the RequestHandler will look for this parameter in the route and set the
language accordingly. In the event that the locale is not supported by the server will
respond with a HTTP 404 NOT FOUND localized in the default locale. The behavior above
also allows for the explicit declarations of localized routes. Setting the "localized"
property on the route definition is there for the convenience of developers to avoid
explicitly listing the routes for each locale. However, if a developer wishes to limit
the supported localizations for the controller explicitly specifying the routes will be
necessary.

In order to support the above a new feature will be added to the RequestHandler. The
ability to register a callback for a route parameter will be provided. By default, a
callback for setting the localization for the request will be provided.

When a controller is selected by the RequestHandler for rendering the route an additional
context parameter will be passed to the controller for localized routes, "routeLocalized".
When set to true and the controller inherits from and executes the BaseController's "init"
function a function will be registered with the instance of TemplateService that will
generate link elements for each of the supported locales. The local registrant will
execute when the "localized_alternate" flag is encountered by the template service. An
example result of the replacement would be:

Assume current URL is: https://careerbuildercareers.com/about

<head>
  ...
  <link rel="alternate" href="https://careerbuildercareers.com/en-us/about" hreflang="en-us" />
  <link rel="alternate" href="https://careerbuildercareers.com/es-es/about" hreflang="es-es" />
  <link rel="alternate" href="https://careerbuildercareers.com/po-po/about" hreflang="po-po" />
  ...
</head>

In order to better support redirects to specific content and locales the
UrlService.createSystemUrl will take an option to provide locale which will be injected
after the end of the site root but before the beginning of the route path.

We are targeting mid december for full implementation. Let us know what you think and if
this solves the upcoming needs for you all.

Member

brianhyder commented Oct 21, 2015

Design:

We need to support localized routes in order to be more SEO friendly. This means that:

https://careerbuildercareers.com/
https://careerbuildercareers.com/en-us

will go to the same location and will provide English (assumes that the default locale is
set to en-US). The design will also provide functionality such that when provided:

https://careerbuildercareers.com/es-es

the site will provide the same location as the URLs denoted above but localized to Spanish.
The existence of the route parameter will prioritize setting the user's locale for the
request by the locale in the route above retrieving it from the user setting and
accept-languages header. In the case of localized routes such as home pages where a
locale is not provided the locale will be chose by the user preference or fall back to the
accept-languges header.

Each route (page or view) must identify itself as "localized" in the route's definition.
An example is provided below:

    SomeViewController.getRoutes = function(cb) {
        var routes = [
            {
                method: 'get',
                path: "/about",
                handler: "render",
                content_type: 'text/html',
                localization: true
            }
        ];
        cb(null, routes);
    };

The above "localization" property set to true will indicate that the route should be
registered multiple times; one for the route with out a locale prefix and one for each of
the supported locales. Therefore, the above route definition would result in the
following routes (NOTE: this is not exhaustive and is bound by the locales available at
startup):

https://careerbuildercareers.com/about
https://careerbuildercareers.com/en-us/about
https://careerbuildercareers.com/es-es/about
https://careerbuildercareers.com/po-po/about

The first version will not attempt to resolve or detect cases where routes are defined
explicitly with locales in the route definitions. The first version will also not support
the ability to specify which locales are available to the route at time of definition.

When a route is registered and the localization property is enabled (FALSE by default) the
RequestHandler will prefix the route with a route parameter ":locale". During route
evaluation the RequestHandler will look for this parameter in the route and set the
language accordingly. In the event that the locale is not supported by the server will
respond with a HTTP 404 NOT FOUND localized in the default locale. The behavior above
also allows for the explicit declarations of localized routes. Setting the "localized"
property on the route definition is there for the convenience of developers to avoid
explicitly listing the routes for each locale. However, if a developer wishes to limit
the supported localizations for the controller explicitly specifying the routes will be
necessary.

In order to support the above a new feature will be added to the RequestHandler. The
ability to register a callback for a route parameter will be provided. By default, a
callback for setting the localization for the request will be provided.

When a controller is selected by the RequestHandler for rendering the route an additional
context parameter will be passed to the controller for localized routes, "routeLocalized".
When set to true and the controller inherits from and executes the BaseController's "init"
function a function will be registered with the instance of TemplateService that will
generate link elements for each of the supported locales. The local registrant will
execute when the "localized_alternate" flag is encountered by the template service. An
example result of the replacement would be:

Assume current URL is: https://careerbuildercareers.com/about

<head>
  ...
  <link rel="alternate" href="https://careerbuildercareers.com/en-us/about" hreflang="en-us" />
  <link rel="alternate" href="https://careerbuildercareers.com/es-es/about" hreflang="es-es" />
  <link rel="alternate" href="https://careerbuildercareers.com/po-po/about" hreflang="po-po" />
  ...
</head>

In order to better support redirects to specific content and locales the
UrlService.createSystemUrl will take an option to provide locale which will be injected
after the end of the site root but before the beginning of the route path.

We are targeting mid december for full implementation. Let us know what you think and if
this solves the upcoming needs for you all.

@btidwell

This comment has been minimized.

Show comment
Hide comment
@btidwell

btidwell Oct 22, 2015

Contributor

Hey Brian,

This definitely is definitely heading in the right direction with what we are looking for. I do have a couple of items I would like to add on to what you have so far if possible. Let me know if you have any suggestions on how else we could approach this case.

Since we are running many sites, some sites might only need to support a subset of all localizations supported by the system. (We would like to 404 all locales in which the site does not have content for).

Could we add two localization config items on a site by site basis? Maybe two additional fields on the create/edit site form? With defaults for backwards compatibility of course.

  • Localizations that are supported (could be a multi-select box showing localizations supported by the system)
  • Default Localization (Drop down that is populated when the Localizations supported field is filled out).

Could each request be set with a locale value that is validated with the specific site's locale config under the following waterfall?

  • Locale variable in the url
  • User preference
  • Accept-Language Request Header
  • Default declared on the site
  • Default declared system wide somewhere in pb.config (with its default being en-us)
Contributor

btidwell commented Oct 22, 2015

Hey Brian,

This definitely is definitely heading in the right direction with what we are looking for. I do have a couple of items I would like to add on to what you have so far if possible. Let me know if you have any suggestions on how else we could approach this case.

Since we are running many sites, some sites might only need to support a subset of all localizations supported by the system. (We would like to 404 all locales in which the site does not have content for).

Could we add two localization config items on a site by site basis? Maybe two additional fields on the create/edit site form? With defaults for backwards compatibility of course.

  • Localizations that are supported (could be a multi-select box showing localizations supported by the system)
  • Default Localization (Drop down that is populated when the Localizations supported field is filled out).

Could each request be set with a locale value that is validated with the specific site's locale config under the following waterfall?

  • Locale variable in the url
  • User preference
  • Accept-Language Request Header
  • Default declared on the site
  • Default declared system wide somewhere in pb.config (with its default being en-us)
@brianhyder

This comment has been minimized.

Show comment
Hide comment
@brianhyder

brianhyder Oct 22, 2015

Member

Sounds like a plan to me. I'll update the design. Side Question: Would
you guys have bandwidth to make the changes to the site UI? Then I can
update the waterfall once that is in place.

On Thu, Oct 22, 2015 at 3:54 PM, Ben Tidwell notifications@github.com
wrote:

Hey Brian,

This definitely is definitely heading in the right direction with what we
are looking for. I do have a couple of items I would like to add on to what
you have so far.

Can we add two localization config items on a site by site basis? Maybe
two additional fields on the create/edit site form? With defaults for
backwards compatibility of course.

  • Localizations that are supported (could be a multi-select box
    showing localizations supported by the system)
  • Default Localization (Drop down that is populated when the
    Localizations supported field is filled out).

Could each request be set with a locale value that is validated with the
specific site's locale config under the following waterfall?

  • Locale variable in the url
  • User preference
  • Accept-Language Request Header
  • Default declared on the site
  • Default declared system wide somewhere in pb.config (with its
    default being en-us)


Reply to this email directly or view it on GitHub
#501 (comment)
.

Brian P. Hyder

Member

brianhyder commented Oct 22, 2015

Sounds like a plan to me. I'll update the design. Side Question: Would
you guys have bandwidth to make the changes to the site UI? Then I can
update the waterfall once that is in place.

On Thu, Oct 22, 2015 at 3:54 PM, Ben Tidwell notifications@github.com
wrote:

Hey Brian,

This definitely is definitely heading in the right direction with what we
are looking for. I do have a couple of items I would like to add on to what
you have so far.

Can we add two localization config items on a site by site basis? Maybe
two additional fields on the create/edit site form? With defaults for
backwards compatibility of course.

  • Localizations that are supported (could be a multi-select box
    showing localizations supported by the system)
  • Default Localization (Drop down that is populated when the
    Localizations supported field is filled out).

Could each request be set with a locale value that is validated with the
specific site's locale config under the following waterfall?

  • Locale variable in the url
  • User preference
  • Accept-Language Request Header
  • Default declared on the site
  • Default declared system wide somewhere in pb.config (with its
    default being en-us)


Reply to this email directly or view it on GitHub
#501 (comment)
.

Brian P. Hyder

@btidwell

This comment has been minimized.

Show comment
Hide comment
@btidwell

btidwell Oct 22, 2015

Contributor

Yes we should have the bandwidth to update the UI. Should be a fairly simple task. Does this include updating the site object both in DB and in memory?

Contributor

btidwell commented Oct 22, 2015

Yes we should have the bandwidth to update the UI. Should be a fairly simple task. Does this include updating the site object both in DB and in memory?

@brianhyder

This comment has been minimized.

Show comment
Hide comment
@brianhyder

brianhyder Oct 22, 2015

Member

Yes, please.
On Oct 22, 2015 4:18 PM, "Ben Tidwell" notifications@github.com wrote:

Yes we should have the bandwidth to update the UI. Should be a fairly
simple task. Does this include updating the site object both in DB and in
memory?


Reply to this email directly or view it on GitHub
#501 (comment)
.

Member

brianhyder commented Oct 22, 2015

Yes, please.
On Oct 22, 2015 4:18 PM, "Ben Tidwell" notifications@github.com wrote:

Yes we should have the bandwidth to update the UI. Should be a fairly
simple task. Does this include updating the site object both in DB and in
memory?


Reply to this email directly or view it on GitHub
#501 (comment)
.

@cchatham

This comment has been minimized.

Show comment
Hide comment
@cchatham

cchatham Oct 23, 2015

Contributor

@brianhyder @blakecallens do you mind reminding us how we can leverage custom objects to keep the localized versions of content pages/articles?

Contributor

cchatham commented Oct 23, 2015

@brianhyder @blakecallens do you mind reminding us how we can leverage custom objects to keep the localized versions of content pages/articles?

@blakecallens

This comment has been minimized.

Show comment
Hide comment
@blakecallens

blakecallens Oct 23, 2015

Member

If you have a custom object with a wysiwyg and peer objects for language and article, then you can add logic to your controller to pull the custom object content, unless you're in the default locale.

Member

blakecallens commented Oct 23, 2015

If you have a custom object with a wysiwyg and peer objects for language and article, then you can add logic to your controller to pull the custom object content, unless you're in the default locale.

@cchatham

This comment has been minimized.

Show comment
Hide comment
@cchatham

cchatham Nov 19, 2015

Contributor

Hi @brianhyder,

So I am sorry I didn't catch this earlier but I have a small issue with this part:

Assume current URL is: https://careerbuildercareers.com/about

<head>
  ...
  <link rel="alternate" href="https://careerbuildercareers.com/en-us/about" hreflang="en-us" />
  <link rel="alternate" href="https://careerbuildercareers.com/es-es/about" hreflang="es-es" />
  <link rel="alternate" href="https://careerbuildercareers.com/po-po/about" hreflang="po-po" />
  ...
</head>

If the site has a default of en-us, https://careerbuildercareers.com/about and https://careerbuildercareers.com/en-us/about are duplicated content and isn't good for SEO. So the default locale for the site needs to be rel="canonical" instead of rel="alternate".

Also, the urls are case sensitive. https://careerbuildercareers.com/en-US/about has to have the uppercase US to work in the current implementation. I think all routes are case sensitive. Was that a intended design decision?

Thanks Brian!!!

Contributor

cchatham commented Nov 19, 2015

Hi @brianhyder,

So I am sorry I didn't catch this earlier but I have a small issue with this part:

Assume current URL is: https://careerbuildercareers.com/about

<head>
  ...
  <link rel="alternate" href="https://careerbuildercareers.com/en-us/about" hreflang="en-us" />
  <link rel="alternate" href="https://careerbuildercareers.com/es-es/about" hreflang="es-es" />
  <link rel="alternate" href="https://careerbuildercareers.com/po-po/about" hreflang="po-po" />
  ...
</head>

If the site has a default of en-us, https://careerbuildercareers.com/about and https://careerbuildercareers.com/en-us/about are duplicated content and isn't good for SEO. So the default locale for the site needs to be rel="canonical" instead of rel="alternate".

Also, the urls are case sensitive. https://careerbuildercareers.com/en-US/about has to have the uppercase US to work in the current implementation. I think all routes are case sensitive. Was that a intended design decision?

Thanks Brian!!!

@brianhyder

This comment has been minimized.

Show comment
Hide comment
@brianhyder

brianhyder Nov 20, 2015

Member

I have updated the branch (feature/501) to behave as outlined in your last comment. The routes are case sensitive. It was originally by design. Changing that behavior is a bit out of scope for this issue but happy to revisit it once we have this functionality in place.

Member

brianhyder commented Nov 20, 2015

I have updated the branch (feature/501) to behave as outlined in your last comment. The routes are case sensitive. It was originally by design. Changing that behavior is a bit out of scope for this issue but happy to revisit it once we have this functionality in place.

@cchatham

This comment has been minimized.

Show comment
Hide comment
@cchatham

cchatham Nov 20, 2015

Contributor

Definitely agree that case sensitive routes are out of scope for this feature. We are just used to seeing en-us everywhere but actually en-US is more compliant. :)

We are working the admin console changes this sprint so you should expect to see a pull request from us over the next 2 weeks.

Contributor

cchatham commented Nov 20, 2015

Definitely agree that case sensitive routes are out of scope for this feature. We are just used to seeing en-us everywhere but actually en-US is more compliant. :)

We are working the admin console changes this sprint so you should expect to see a pull request from us over the next 2 weeks.

brianhyder added a commit that referenced this issue Nov 24, 2015

@cchatham

This comment has been minimized.

Show comment
Hide comment
@cchatham

cchatham Nov 24, 2015

Contributor

Hey @brianhyder,

We found a couple more things we are curious about.

  1. Localization supports active theme but it is not leveraged by the RequestHandler. Therefore active theme is not respected. Was this intended?
  2. Could we get some explanation/documentation on the Localization.storage object? It seems more nested and complex than before. We have some ideas about how to simplify it but you probably have a reason for the design we are unaware of.

Due to our schedule, we probably won't pull these changes into our code base until mid to late December so we don't need an answer right away. :)

Thanks!!

Contributor

cchatham commented Nov 24, 2015

Hey @brianhyder,

We found a couple more things we are curious about.

  1. Localization supports active theme but it is not leveraged by the RequestHandler. Therefore active theme is not respected. Was this intended?
  2. Could we get some explanation/documentation on the Localization.storage object? It seems more nested and complex than before. We have some ideas about how to simplify it but you probably have a reason for the design we are unaware of.

Due to our schedule, we probably won't pull these changes into our code base until mid to late December so we don't need an answer right away. :)

Thanks!!

@cchatham

This comment has been minimized.

Show comment
Hide comment
@cchatham

cchatham Dec 15, 2015

Contributor

@brianhyder @blakecallens how would you handle localizing the navigation?
Content we will use the custom object solution for now but not sure how scalable that is going to be.

Contributor

cchatham commented Dec 15, 2015

@brianhyder @blakecallens how would you handle localizing the navigation?
Content we will use the custom object solution for now but not sure how scalable that is going to be.

@brianhyder

This comment has been minimized.

Show comment
Hide comment
@brianhyder

brianhyder Dec 15, 2015

Member

We would probably add the ability to use a localization key as a name for a container or link and then run the name through the localization before the HTML is generated.

Member

brianhyder commented Dec 15, 2015

We would probably add the ability to use a localization key as a name for a container or link and then run the name through the localization before the HTML is generated.

@brianhyder

This comment has been minimized.

Show comment
Hide comment
@brianhyder

brianhyder Dec 15, 2015

Member

I think that would be a relatively easy change in top_menu.js

Member

brianhyder commented Dec 15, 2015

I think that would be a relatively easy change in top_menu.js

@cchatham

This comment has been minimized.

Show comment
Hide comment
@cchatham

cchatham Dec 15, 2015

Contributor

Thanks @brianhyder

Contributor

cchatham commented Dec 15, 2015

Thanks @brianhyder

@blakecallens

This comment has been minimized.

Show comment
Hide comment
@blakecallens

blakecallens Jan 8, 2016

Member

Woot! Thanks for your hard work on this.
On Jan 7, 2016 21:00, "Brian" notifications@github.com wrote:

Closed #501 #501.


Reply to this email directly or view it on GitHub
#501 (comment).

Member

blakecallens commented Jan 8, 2016

Woot! Thanks for your hard work on this.
On Jan 7, 2016 21:00, "Brian" notifications@github.com wrote:

Closed #501 #501.


Reply to this email directly or view it on GitHub
#501 (comment).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment