Re: User's language in URL

Florian Schlittgen <[email protected]> Thu, 15 Jan 2026 07:19:41 +0000
Newsgroups gmane.comp.jakarta.struts.user
Message-ID <[email protected]>
Hi Ute,
although I am pretty sure that I'll go for the Apache rewriting 
approach, I am interested in your solution. Thanks!

Cheers
Florian

On 1/14/26 7:38 PM, [email protected] wrote:
> Hi Florian,
> I had same problem migrating from Struts1 to Struts7
> I solved it with an Interceptor but also used namespace (what you do not want)
> Do you want me to post my solution?
> Kind regards Ute
>
> Gesendet mit der mobilen Mail App
>
> Am 14.01.26 um 13:08 schrieb Florian Schlittgen
>
>> Great, thanks for your quick reply.
>> One comment:
>>> 3. Outbound redirect handling - either via Apache Header edit
>>> directive, or a custom result type that prepends the locale to
>>> Location headers.
>> With the introduction of a custom result type, you rely on the Apache
>> rewriting. If you want to test the application locally without reverse
>> proxy, the redirect will not work. So I rather would go for Apache
>> Header edit directive to rewrite the Location header to only loosely
>> couple Apache to the Struts application.
>>
>> Cheers
>> Florian
>>
>>
>> On 1/14/26 11:47 AM, Lukasz Lenart wrote:
>>> There is no direct support for such a approach in the framework, if
>>> you use Apache HTTP you can add reverse proxy with mod_rewrite plus a
>>> small interceptor, eg.
>>>
>>> 1. Apache mod_rewrite (inbound):
>>>
>>>
>>>
>>> RewriteEngine On
>>>     RewriteCond %{REQUEST_URI} ^/([a-z]{2})(/.*)?$
>>>     RewriteRule ^/([a-z]{2})(/.*)?$ $2 [E=STRUTS_LOCALE:$1,PT]
>>>     RequestHeader set X-Struts-Locale "%{STRUTS_LOCALE}e"
>>> env=STRUTS_LOCALE
>>>
>>> 2. Simple interceptor to read the header:
>>>
>>>     public class UrlLocaleInterceptor extends AbstractInterceptor {
>>>
>>>
>>>                                                        @Override
>>>
>>>
>>>
>>>                                                          public String
>>> intercept(ActionInvocation invocation) throws Exception {
>>>
>>>
>>>                                    HttpServletRequest request =
>>> ServletActionContext.getRequest();
>>>
>>>
>>>               String locale = request.getHeader("X-Struts-Locale");
>>>
>>>
>>>                                                                  if
>>> (locale != null) {
>>>
>>>
>>>
>>>        ActionContext.getContext().withLocale(LocaleUtils.toLocale(locale));
>>>
>>>
>>>                                           }
>>>
>>>
>>>
>>>                                                       return
>>> invocation.invoke();
>>>
>>>
>>>                                                             }
>>>
>>>
>>>
>>>                                                                     }
>>>
>>> 3. Outbound redirect handling - either via Apache Header edit
>>> directive, or a custom result type that prepends the locale to
>>> Location headers.
>>>
>>> Cheers
>>> Łukasz
>>>
>>> śr., 14 sty 2026 o 10:51 Florian Schlittgen <[email protected]> napisał(a):
>>>> Hi,
>>>>
>>>> in my Struts2 application, I want the user's current language to be part
>>>> of the URL. For example:
>>>>
>>>> http://localhost:8080/myApp/en/my/namespace/myAction.action (English)
>>>> http://localhost:8080/myApp/de/my/namespace/myAction.action (German)
>>>>
>>>> Is there a built-in feature in Struts to implement this?
>>>> I am using the convention plugin and the application contains a lot of
>>>> actions and JSP pages, therefore I looking for way to implement this
>>>> without changing existing namespaces or JSP pages.
>>>> Anyone who have done this before or have any advice on this?
>>>>
>>>> Instead of implementing it with Struts, I could use my reverse proxy
>>>> (Apache HTTP) to rewrite requests (strip out the language part from the
>>>> url and turn it into a request parameter). And for the reverse
>>>> direction, redirects coming from Struts backend must also be rewritten
>>>> (transform the 'Location' response header into the URL form from above).
>>>> Any thoughts or advice on this?
>>>>
>>>> Which one would be the better approach?
>>>>
>>>> Kind regards
>>>> Florian
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>