Bạn có thể tham khảo cách làm của mình với project vuejs như sau:

• Cài package "vue-i18n".
• import và use nó ở file "app.js"

import VueI18n from 'vue-i18n';
Vue.use(VueI18n);

const i18n = new VueI18n({
    locale: 'vi', // locale mặc định
    messages,
});

const app = new Vue({
    i18n,
    render: h => h(App),
});

-Thêm folder "locales" với file "index.js" và các file locale.js tương ứng. ở đây mình ví dụ 2 ngôn ngữ là tiếng anh và tiếng việt nội dung file index.js như sau

import en from './en';
import vi from './vi';

export default {
    en,
    vi,
};

file vi.js và en.js sẽ chứa nội dung cần translate dạng như sau file en.js

const en = {
hi: 'Hi ',
}

file vi.js

const vi = {
hi: 'Xin Chào ',
}

-Thêm 1 component switchLanguage, dưới đây là component của mình, bạn có thể style tùy ý

<template>
    <div>
        <select v-model="$i18n.locale" class="switch-locale">
            <option
                v-for="lang in langs"
                :key="lang.key"
                :value="lang.key"
            >
                {{ lang.lable }}
            </option>
        </select>
    </div>
</template>

<script>
    export default {
        name: 'SwitchLocale',
        data() {
            return {
                langs: [
                    {
                        key: 'vi',
                        lable: 'Tiếng việt',
                    },
                    {
                        key: 'en',
                        lable: 'English',
                    },
                ],
            };
        },
    };
</script>

<style>
    .switch-locale {
        width: 130px;
        height: 35px;
        outline: 0;
        border-radius: 4px;
        border: 1px solid #909399d9;
        background: white;
    }
</style>

-Cuối cùng là thay nội dung cần đa ngôn ngữ ở thẻ html ví dụ bạn

<h1> Xin Chào </h1>

Bạn cần chuyển lại thành

<h1> {{ $t('hi') }} </h1>

Chúc bạn thành công

@nhatnguyen123321 đúng rồi, bởi vì queue worker là 1 long-lived process nên code sẽ không thay đổi trên đó nếu như bạn không restart worker

@napmucmayin Bạn phải truyền vào kiểu chuỗi, "6742.70" nhé, hoặc có thể sửa lại theo PR của mình tại đây, sẽ cung cấp thêm phần setDecimalPart: https://github.com/phpviet/number-to-words/pull/8

cảm ơn anh đã chia sẽ, đây là động lực lớn đến các bạn trẻ như em đang theo nghành và các anh chị bạn khác nghành để theo đuổi nghành IT này

Hic, từ cái đoạn anh sử dụng GDB là em mù luôn, chưa hiểu lắm ( Dù sao cũng cảm ơn những chia sẻ của anh!

Cảm ơn bạn nhé.

Cảm ơn bạn nhé.

Thanks bạn viết rất dễ hiểu

giờ mới nhận ra là mình chả hiểu gì về kiểu tham chiếu hết tại trước giờ toàn sài int thôi, thank bài viết nhiều

protected function resolveNumber($number): array { if (! is_numeric($number)) { throw new InvalidArgumentException(sprintf('Number arg (%s) must be numeric!', $number)); }

    //$number += 0; // trick xóa các số 0 lẻ sau cùng của phân số đối với input là chuỗi.
    $number = (string) $number;
    $minus = '-' === $number[0];

    if (false !== strpos($number, '.')) {
        $numbers = explode('.', $number, 2);
    } else {
        $numbers = [$number, 0];
    }

    return array_merge([$minus], array_map('abs', $numbers));
}

Em thử comment và xóa cache nhưng vẫn hok được ạ.

@dao.thai.son như này mỗi lần thêm 1 queue là phải thêm trong file .conf rồi chạy các lệnh reload một lần

@hxtruong6 hi bạn,

1 note trước khi bắt đầu đó là web B hay các web client side rendering nói chung (Vue, React, Angular), khi đã build thì nó sẽ ra file static và nó không thể tự chạy được, mà nó phải được host ở đâu đó, bằng server nào đó (NodeJS, php, python,....) hoặc bằng webserver (nginx, apache....). Khác với SSR (NextJS - web A) hoặc thuần server (như server C)

Trước khi deploy thì bạn cần đặt câu hỏi: bạn có muốn deploy tất cả chúng ở trên 1 domain hay ko? kiểu example.com, example.com/admin, example.com/api. Dựa theo những điều bạn nói thì có vẻ như vậy. Kiểu này sẽ "khó" hơn chút (tí thôi ) (kiểu deploy mỗi cái 1 domain thì sẽ dễ hơn, vì đơn giản là nó tách biệt ko chung chạ ko cần proxy path, location,...)

Cách deploy:

• Build + start web A(nextjs) và server C, cho chúng chạy ở các cổng khác nhau, giả sử 3000, 3001
• Build web B (React JS) được folder static build

Cấu hình Nginx nom sẽ như sau:

server {
  listen 80;
  listen [::]:80;
  server_name example.com;

  # Web B (ReactJS)
  location / {
    root /path_to_build_folder;
    index index.html index.htm index.nginx-debian.html;
    try_files $uri $uri/ /index.html;
  }

  # Web A (NextJS)
  location /admin {
    proxy_pass http://127.0.0.1:3000; # -->> Notice this PORT
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection 'upgrade';
    proxy_set_header Host $host;
    proxy_set_header x-forwarded-for $remote_addr;
    proxy_cache_bypass $http_upgrade;
  }

  # Server C (NodeJS)
  location /api {
    proxy_pass http://127.0.0.1:3001; # -->> Notice this PORT
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection 'upgrade';
    proxy_set_header Host $host;
    proxy_set_header x-forwarded-for $remote_addr;
    proxy_cache_bypass $http_upgrade;
  }
}

Với cách này thì Nginx sẽ serve Web B (ReactJS) như các trang HTML thông thường, nếu client request vào url mà có prefix là /api hoặc /admin thì proxy request vào các backend tương ứng (backend ở đây sẽ là nextjs và nodejs)

P/s: còn 1 vài cách deploy khác, mình ko muốn bạn thấy rối khi giới thiệu nhiều cách, cứ làm dần dần tìm hiểu dần nhé, cách này mình hay dùng và thấy đơn giản nhất

@tvh95 việc lưu dạng display-time không phải là bắt buộc mà là một gợi ý 😄 và tất nhiên sẽ tùy vào trường hợp mới lưu ở dạng display (như thời gian lặp đi lặp lại của 1 ca làm việc, của các ngày lễ hằng năm...)

Chung quy mọi vấn đề liên quan đến ngày giờ đều nằm ở việc, các thành viên trong dự án có nhất quán với quy tắc thiết kế & lưu trữ đã đưa ra ban đầu hay không mà thôi.

đúng rồi bạn

@nambach custom timezone không vấn đề gì bạn ạ. DB sẽ lưu thiết định timezone của người dùng. Ví dụ người dùng đang ở VN nhưng muốn hiển thị thời gian theo giờ Nhật, thì chúng ta lưu trường timezone = 9 vào bảng user config nào đấy. Phía frontend sẽ call api để get ra 2 giá trị: thời gian và timezone của người dùng. Sau đó dùng thư viện moment.js để chuyển đổi. Ví dụ:

const startTime = moment().utc(dateString).tz(timezone);

console.log(startTime.format("DD-MM-YYYY HH:mm"));

Format hiển thị nên để cho frontend làm.

Hơn nữa, nếu lưu dạng display-time, thì sau này người dùng đổi thiết định timezone thì làm sao sửa một loạt các giá trị đã lưu từ trước đây.

Cảm ơn bạn, góp ý chuẩn quá.

Đây là một hướng tiếp cận "an toàn", nghĩa là chúng ta không đụng vào flow của dữ liệu từ back đến front. Tuy nhiên trong trường hợp user có nhu cầu tự custom timezone, thì lưu ở dạng display-time sẽ tiện hơn là timestamp, và nên có 1 số điều chỉnh trong thiết kế UI.

Edited: và trong trường hợp rtime đã mô tả ở trên, với những case lặp lịch mang tính tuần hoàn, mà chúng ta muốn lazy-scheduling, thì mình nghĩ lưu display-time sẽ tiện hơn, miễn là kèm theo thông tin timezone (lưu theo user hoặc global trong hệ thống - tùy cách mình thiết kế) 😁

Không những vậy, việc mapping kiểu dữ liệu ở phía backend - DB cũng có thể gặp rắc rối nếu không xem xét cẩn thận ngay từ đầu. Mình có đề cập những vấn đề này ở bài viết tiếp theo, bạn có thể xem link cuối bài viết này nhe.

Em thì ko code Java, nên chỉ biết note lại sau này đọc. Em xin chia sẻ thêm với các bác kinh nghiệm khi xử lý thời gian có liên quan đến timezone ở phía frontend (bằng Javascript). Chuỗi thời gian bắt buộc phải có yếu tố timezone, tức là có định dạng "2020-10-04T01:55:00Z" (có chữ "Z" ở cuối), hoặc "2020-10-04 01:55:00 GMT+0700". Nếu không, khi khởi tạo đối tượng Date trong Javascript, nó sẽ hiểu đấy là thời gian của local, và nó sẽ tự động ghép múi giờ của local vào. Điều này dẫn đến bao nhiêu lỗi lệch ngày, lệch giờ khi xử lý timezone. Để thống nhất thời gian, cách tốt nhất là backend chỉ nên đọc nguyên vẹn thời gian kiểu timestamp từ DB, lúc lưu cũng phải lưu chuỗi thời gian kiểu timestamp, phía frontend cũng phải đọc nguyên vẹn chuỗi ấy để chuyển đổi hiển thị (không làm gì thì nó vẫn hiển thị đúng thời gian theo múi giờ của local). Nếu có yêu cầu chuyển đổi thời gian hiển thị theo thiết định timezone của người dùng thì cũng dễ dàng và không bị bug. Cả Javascript thuần hay thư viện đều có thể làm được. Nếu không có yếu tố timezone trong chuỗi thời gian thì có dùng thư viện trời bể gì đi chăng nữa cũng convert sai.

Chỗ này bị sai rồi, bạn sửa lại nhé sudo ln -s /etc/nginx/site-available/test-ssl /etc/nginx/site-enabled thành sudo ln -s /etc/nginx/sites-available/test-ssl /etc/nginx/sites-enabled

@hmquan08011996 cảm ơn bạn. do mình mới tiếp xúc tới IT và bắt đầu từ docker container luôn nên không hiểu trước đây người ta deploy như thế nào. giờ mình rõ hơn rồi. cảm ơn bạn nha.

@npham giờ thì mọi người đang chuyển dần dần sang xài container và chuyển server của mình lên AWS